Jboss 7 - transaction behaviour - clarification needed

[skorepam]

Hello.

I would like to clarify transaction behaviour in Jboss AS 7.1.1.

We have an application where all transactions are managed by container.

Scenario used:

- A message driven is doing some job. It is container managed which means that it starts Transaction (T1) - this is top level transaction

- Within its processing it invokes stateless EJB business method (B2) annotated by @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW).

Transaction T2 is started at the moment. It changes some data in object "A" using injected stateless DAO EJB. The businesss method ends which means that T2 is commited.

- Data changed in "A" object within T2 are visible in MDB (T1) when T2 ends.

- T1 invokes another business method B3 - new transaction T3 is started again @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). Within this transaction data changed in object "A" are not visible. The orignal value is populated there.

- All changes made in T1, T2, T3 are persisted to database when T1 commits. Which means that T2 and T3 are nested to T1.

Please could you clarify that

- this is corect behaviour. I beleive so. I found this article:

https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/5/html/Transactions_Development_Guide/ch11.html#idp7648512

11.1.4. Nested Transactions

You do not need to do anything special to nest transactions. If an action is begun while another action is running, it is automatically nested. This provides a modular structure to applications,meaning that the programmer of the object does not need to be concerned about whether the applications to use the object are also transactional.

If a nested action is aborted then all of its work is rolled back. However, strict two-phase locking means that any locks the terminating transaction holds are retained until the top-level action commits or aborts. If a nested action commits, the work it has performed is only committed by the system if the top-level action commits. If the top-level action aborts, all the work is rolled back.

Committing or aborting a nested action does not automatically affect the outcome of its parent action. You can choose to implement this behavior programmatically, controlling the way faults are contained or work is undone, for instance.

- is it possible to make data changed in "A" visible to T3?

- how can I create independet Top - level transactions. It should be somehow possible. From the article above:

11.1.6. Independent Top-Level Transactions

In addition to normal top-level and nested transactions, JBoss Transaction Service also supports independent top-level actions, which you can use to relax strict serializability in a controlled way. You can execute an independent top-level action from anywhere within another transaction, and it behaves exactly like a normal top-level action. Its results are made permanent when it commits and are not undone if any of its parent actions abort

.

I forgot to menton that the application is using XA datasource, JPA (Hibernate).

Many thanks.

Martin

[jhalliday]

you're running independent top-level already as that's your only option in JTA/XA.  The core tx engine supports true nesting, but the resource managers don't.

http://jbossts.blogspot.co.uk/2011/10/nested-transactions-101.html

[skorepam]

Jonathan, many thanks for quick reply.

trying to understand it correctly but being more confused rigth now. Yesterday we've done following test scenario:

MDB starts T1

it starts T2 - within T2 data are changed. T2 is container based, once the business method ends data should be commited in database - but it isn't, why? it is only when T1 commits

T1 then throws RuntimeException - T1 rolls back thats ok, data changed in T2 are rolled back too - why? shouldn't they be commited as per your post?

thanks again

[jhalliday]

> T2 is container based, once the business method ends data should be commited in database - but it isn't, why? it is only when T1 commits

assuming T2 is REQUIRES_NEW that's incorrect.  How are you observing that behaviour? The effects of T2 may not be visible within T1 even after T2 commits, depending on the isolation behaviour of the RM. It should be immediately visiable to any tx starting after T2 commits.

> T1 rolls back ...data changed in T2 are rolled back too - why?

That's also incorrect - T2 can't roll back as it's already committed. Sounds like you don't actually have independent tx at all here. Sure you're accessing B2 through the managed interface rather than directly?

[skorepam]

You got it!

B2 was not accessed by the interface while B3 was. This was the cause why T3 can't see any changes made in T2 . They have been in fact done in T1 and T2 never exist.

Many thanks for your help.