The problems with recovery

• or - why this thing doesn't work yet

While the most common usage of transaction managers is the coordination of transactional resources with a protocol like 2PC, another critical aspect of their usage comes from the ability to recover transactions that have failed due to system crash, be that the transaction manager itself, another coordinating resource (like the OS) or one of the participating resources. For the rest of this text, we will focus on XA compliant transactional systems (transaction manager + transactional resources) as implemented by JTA.

While the JTA specification is very descriptive of almost all the aspects of distributed transactions, including the recovery process, it leaves out a critical issue: how the XA resources that participated in a global transaction that was not decided upon because of a crash will register with and inform the coordinating transaction manager of the xid of dangling local transactions, their vote etc. Because of that, every implementation has its own way of dealing with the issue (for example, JOTM is simply happy to have instances of XAResource registered and recovery being asked for explicitly while JBoss asks for serialized objects to be available somewhere for retrieval).

This leads to a situation where having true distributed transactions with JTA in a manner transparent over the actual txm implementation is next to impossible. While the instantiation/retrieval of the TransactionManager object can be abstracted, the recovery process is too tightly bound to the lifecycle of the applications that implement XAResource and of the way the txm implementation does recovery.

The question here is of course how does Spring fare on this aspect, since it provides a uniform access method irrespective of the actually plugged in implementation of the txm. If it indeed succeeds in transparently handling recovery after crashes then there are no problems and everything should work as expected simply by registering resources in the Transaction object. If, however, there is no such facility in place yet, then recovery cannot work. Let's see an example

If I have configured jotm as the txm implementation, then I can simply retrieve the object (as a TransactionManager) from the org.springframework.transaction.jta.JtaTransactionManager and have my XAResources registered there. The same goes for every other part that is ready to participate in 2PC and the user is blissfully unaware of the actual workings. However, if the system crashes, then jotm expects calls to Current.getTransactionRecovery().registerResourceManager() that will register all previously used resources and then a call to Current.getTransactionRecovery().startResourceManagerRecovery() to actually recover all pending txs. JBoss does this differently, as does Atomikos etc. Also, this call must be blocking because there is no requirement that a XA compatible storage system must be able to serve requests while transactions are pending. Neo4j, for instance, will not serve requests while the store is not restored to a clean state.

So, the question for the Spring hackers is, how do you provide recovery guarantees for all TransactionManager implementations you support while hiding the details from the XA enabled components running in your framework? Or, to be more specific, if Neo4j uses the user configured, external txm implementation via the Spring interfaces, what steps/API should it use to ensure that it will be recovered after a crash?

-- Edited by Chris Gioran