JTA specs clarification .

[vickyk]

Looking at the JTS specs at section3.2 TransactionManager Interface
I could find following lines

"A thread?s transaction
context is either null or it refers to a specific global transaction."
Under what scenario will the Transactional context be null .

Another line
" Multiple threads may
concurrently be associated with the same global transaction"

Under what circumstance will multiple threads be a part of the same transaction , I am not able to comprehend it clearly
Can I have some explanation about the same ?l

[marklittle]

The context will be null if the thread is not associated with a transaction. Easiest scenario: you create a new thread and it won't be associated with a transaction.

Multiple threads MAY be associated with the same transaction, but that's implementation specific: some don't allow it. JBoss Transactions does, however. One scenario is where you've got lots of worker threads doing stuff on behalf of an application in the scope of the same transaction. Those threads could be within the same VM or within different VMs (if you've got distributed transactions). If they are in the same VM, then you need some kind of checked transaction policy to ensure that one thread doesn't terminate the transaction while the others are still working.

Mark.

[svpooni70]

mark,

Imagine we need to have multiple threads executing in the scope of the same transaction. The global transaction identifiers of transactions in both threads need to be the same right ? But if you start a JTA-transaction tx, the current thread becomes associated with tx. Being in the current thread, if you then start another thread, it is not associated with tx. You can't set a user-defined transaction XID in JTA. How do we handle this situation ?

[marklittle]

This depends on your JTA implementation. Some implementations don't support multiple threads in the scope of the same transaction. JBossTS isn't one of those ;-)

You have a number of options available to you. However, the easiest one would be to get a reference to the current transaction in the thread that created it and pass it to the thread you want to join. Then do a resume.

One word of warning though: once you have multiple threads in the same transaction you enter the domain of needing Checked Transaction semantics. Check out some of the papers on our labs page for this, but basically in general you don't want to end up in the situation where a thread terminates the transaction while the other threads are still using it. JBossTS has a CheckedAction class that you can associate with each transaction to allow you to do implementation specific rendezvous if that happens.