The additional observation I had was that in a JTA+JTS environment where, as JTS is a remote protocol and uses a thread pool to handle remote invocation, it can be any thread performing completion (commit/rollback, and hence afterCompletion) on a transaction and therefore afterCompletion can (and likely will) be called from a different thread than the one that registered the SynchronizationCallbackCoordinatorImpl. Therefore, examples of where you might be asked to process completion in a different thread from the one you did your app work on are both timeouts and normal completion events initiated by remote servers .

From what I can understand in this scenario of remote completion, your Session instance would never be invoked again (as the application thread is now done) which will mean that you won't necessarily be given another opportunity to process doAfterCompletion() using the thread that registered the SynchronizationCallbackCoordinatorImpl. Clearly, I can't be certain unless I know how you intend to invoke doAfterCompletion() from the Session::* methods. For example, if a new Session is created on the same thread as was used previously (but doAfterCompletion had not been processed) maybe it will "garbage collect" (doAfterCompletion) the previous threads session if it sees it is waiting for completion handling. Or perhaps you intend to put the cleanup in the finalize method of the Session?