Kevin Conner wrote: > As an aside, having just looked at the 3.0.1 code (this may > have changed since then), commit, delistResource, enlistResource, > registerSynchronization, rollback and setRollbackOnly are protected > by the lock method (and hence synchronisation).
Until my recent commit, the 3.0.1 tx code and the 3.1alpha code was the same, though placed in different CVS modules. > The getStatus and getTransactionImpl methods aren't (and their > respective variables aren't volatile) which means they may > suffer from the same problem as the double checked locking. > If these variables are modified within one thread, are not > covered by synchronisation, then the changes may not be visible > in other threads. I see no problem with the getTransactionImpl() method. The member variable txCapsule.transaction is _only_ set when a new transaction is started, and does not change until said transaction ends. But getTransactionImpl() is only called by the TxManager, and always on the same thread that just set variable txCapsule.transaction. For txCapsule.getStatus(), having txCapsule.status non-volatile means that it may return an old status value, if another thread has just changed the status. But unlike the double checked locking example, the return value is a primitive and not an object that may not yet be initialized. However, in the general case, a call to javax.transaction.getStatus() may return a status that is outdated before the calling thread uses it, and JTA has no way of protecting against that. Thus, I do not consider the chance of delivering an outdated status value for being bad enough that I wanted to add code to protect against it. But: This code is all way to hairy, and I would really like to just synchronize on the frontend - even if that would lead to deadlock with some weird calling sequences that are technically allowed by JTA (see my reply to Dain Sundstrom). Best Regards, Ole Husgaard. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
