3 Replies Latest reply on Jan 4, 2006 6:37 PM by manik

    Calling commit/rollback on remotely initiated tx

    brian.stansberry

      AFAICT in the current 1.3 code, Transaction.commit() or Transaction.rollback() are never called on transactions that are initiated due to a prepare() call from a remote cache. Our own code handles the commit/rollback of operations on the cache, but if any user code has used TreeCacheListener to register a Synchronization on the tx, they won't get the beforeCompletion()/afterCompletion() calls.

      Stumbled into this because a unit test I wrote in 1.2.4SP1 for JBCACHE-359 this does just that :-). Suddenly didn't work in 1.3.

      Also, in 1.3 it looks like the TxInterceptor doesn't register as a Synchronization either. I believe this means that if a remote prepare() call is successfully executed but then the originating cache crashes and never sends a commit or rollback, when the local tx created by the prepare() call times out and rolls back, the cache changes made as part of the prepare() won't be reversed, locks won't be released, etc.

      Note for users of TreeCache interested in the subtleties of its tx handling: Once the above mentioned issue gets resolved, even if user code does register a Synchronization on this kind of tx, and then calls tx.setRollbackOnly() during the beforeCompletion() phase, the rollback will not propagate back to originating cache. This is because the commit/rollback on the remote cache is called as part of a Synchronization.afterCompletion() call on the originating cache. At that point, the tx on the originating cache cannot be rolled back. Besides, the commit/rollback call is asynchronous, so the originating cache never gets a response. Having this call be asynchronous makes sense, since the fact that the remote commit()/prepare() is called as part of afterCompletion() means the originating cache can't do anything with a response anyway.

        • 1. Re: Calling commit/rollback on remotely initiated tx

          1. Havn't looked at the 1.3 code closely. But we should try to revert the semantics back unless there is a reason for it.

          2. For the last issue, I think the proper solution is a strict 2pc protocol. But it will be costly, I am afraid. Maybe, in the future, we can make this an option for users that need more strict *correctness*?

          • 2. Re: Calling commit/rollback on remotely initiated tx
            manik

            Hi Brian

            Thanks for spotting this, yes, this is a major problem that crept in when refactoring the OptimisticTxInterceptor for 'general use'. I'll look into this and sort it out.

            • 3. Re: Calling commit/rollback on remotely initiated tx
              manik

              Hi,

              This is now fixed in CVS, but note that calls to tx.setRollbackOnly() during the beforeCompletion() phase will not propagate the rollback back to the originating cache because the commits and rollbacks on remote caches are called as part of a Synchronization.afterCompletion() call on the originating cache, just as Brian mentioned above.

              I'll spend a few cycles looking into what the overhead would be like to implement a proper 2PC commit here, but this still does need more thought and discussion.

              Cheers,
              Manik