How to design global distributed transaction(none database)? Can JTA use for none db transaction?

Question

I think this is a fairly common question: how to put my business logic in a global transaction in distributed systems environment? Cite an example, I have a TaskA containing couples of sub tasks:

TaskA {subtask1, subtask2, subtask3 ... }

each of these subtasks may execute on local machine or a remote one, I hope TaskA executes in an atomic manner(success or fail) by means of transaction. Every subtask has a rollback function, once TaskA thinks the operation fails(because one of subtask fails), it calls each rollback function of subtasks. Otherwise TaskA commits the whole transaction.

To do this, I follow "Audit trial" transaction pattern to have a record for each subtask, so TaskA can know operation results of subtasks then decide rollback or commit. This sounds like simple, however, the hard part is how to associate each subtask to the global transaction?

When TaskA begins, it starts a global transaction about which subtask knows nothing. To make subtask aware of it, I have to pass the transaction context to every invocation of subtask. This is really dreadful! My subtask may either execute in a new thread or execute in remote by sending a message through AMQP broker, it's hard to consolidate the way of context propagation.

I did some research like "Transaction Patterns - A Collection of Four Transaction Related Patterns", "Checked Transactions in an Asynchronous Message Passing Environment", none of these solve my problem. They either don't have practical example or don't solve the context propagation issue.

I wonder how people solve this? as this sort of transaction must be common in enterprise software.

Is X/Open XA only the solution for this? Can JTA help here(I have't look into JTA as most stuff for it relate to database transaction, and I am using Spring, I don't want to involve another Java EE application server in my software).

Can some expert share some thoughts with me? thank you.

Conclusion

Arjan and Martin gave out really good answers, thank you. Finally I didn't go with this way. After more research, I chose another pattern "CheckPoint" 1.

Looking into my requirement, I found my intention to "Audit Trial Transaction Pattern" is to know which level the operation has proceeded to, if it's failed, I can restart it at the failed spot after reloading some context. Actually this is not transaction, it didn't rollback other successful steps after failure. This is essence of CheckPoint pattern. However, studying distributed transaction stuff makes me learned lot of interesting things. Apart from what Arjan and Martin have mentioned. I also suggest people digging into this area take a look at CORBA which is a well-known protocol for distributed system.

Answer 1

You're right, you need two-phase commit support thanks to a XA transaction manager provided by the JTA API.

As far as I know Spring does not provide a transaction manager implementation itself. The JtaTransactionManager only delegates to existing implementation usually provided from JavaEE implementations.

So you will have to plugin a JTA implementation into Spring to get effective job done. Here are some proposals:

• JOTM
• JBossTS based on Arjuna.
• Atokimos

Then you will have to implement your resource manager to support two-phase commit. In the JavaEE worlds, it consists in a resource adapter packaged as a RAR archive. Depending on the type of resource, the following aspects are to read/implement:

• XAResource interface
• JCA Java Connector Architecture mainly if a remote connection is involved
• JTS Transaction Service if transaction propagation between nodes is required

As examples, I recommend you to look at implementations for the classical "transactions with files" issue:

• the transactional file manager from JBoss Transactions
• XADisk project