mark.little(a)jboss.com wrote : | [...] | Thanks for your answers. I still have a few more questions though :) I have looked for references to CheckedAction in the JTS Programmer Guide, and did find a paragraph about async checked transactions. It is at page 51 of the JTS Programmer Guide: Checked transaction behaviour, but after reading it I'm still a bit confused. A/ What are the responsabilities of JBossTS and of the programmer, and how should i override CheckedAction? 1/At page 51 of the JTS Programmer Guide: Checked transaction behaviour anonymous wrote : | Some Transaction Service implementations will enforce checked behaviour for the transactions they support, to provide an extra level of transaction integrity. | The purpose of the checks is to ensure that all transactional requests made by the application have completed their processing before the transaction is committed. | A checked Transaction Service guarantees that commit will not succeed unless all transactional objects involved in the transaction have completed the processing of their transactional requests. | What i understand is that the Transaction Service does the checks. He knows what transactional objects are involved in the transaction. He won't commit before all of them are done processing their transactional requests (so i suppose he blocks until they're done?). 2/Then in the The JBossTS specifics paragraph: anonymous wrote : | By default, JBossTS will issue a warning if a thread terminates a transaction when other threads are still active within it; however, it will allow the transaction termination to continue. | Other solutions to this problem are possible, e.g., blocking the threadwhich is terminating the transaction until all other threads have disassociated themselves from the transaction context. | Therefore, JBossTS provides the com.arjuna.ats.arjuna.coordinator.CheckedAction class, which allows the thread/transaction termination policy to be overridden. Each transaction has an instance of this class associated with it, and application programmers can provide their own implementations on a per transaction basis. | What i understand is that when the transaction tries to commit, JBTS is aware of threads that are still active. But then it's up to the programmer to block the transaction-owning thread until the active threads are done. He does so by implementing a callback (the CheckedAction implementation), that will be called by JBTS before committing the transaction. 3/The javadoc for CheckedAction also says that if you don't override it, the default just prints a warning in case threads still active. And in the source there is this comment on the check method: anonymous wrote : | Called during transaction termination if more than one thread is associated with the transaction. | The supplied information should be sufficient for application specific implementations to do useful work (such as synchronizing on the threads). | But JBTS does know which threads are still active right? Then shouldn't the programmer just need to decide whether to commit now or block? I don't see references to Threads in the parameters of method check, maybe they are in the Hashtable parameter? But isn't it the TS that should be the one blocking them (or not, depending on the policy defined by the programmer's override of CheckedAction)? Otherwise isn't it a bit contradictory (at least in spirit) with the declarative approach of Container Managed Transactions? B/ In the same paragraph, i also don't understand what this means. What does the transaction manager need to be co-located with? anonymous wrote : | Checked transactions are only possible if using a co-located transaction | manager, i.e., the use of a separate transaction manager processes does | not allow checked transactions to be provided by the system. | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4255934#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...