Spring distributed transaction related to RMI calls?

Question

Background

I have a Spring client application that provides a service to two servers using RMI. In the client, I save the object in the database (easily) and make rmi calls to two servers with detailed information about the object. I use Spring 3.0.2 on servers, and the client is a simple Spring -mvc site.

Requirements

My requirement is that if any of the rmi calls does not allow the servers to reload the entire transaction, then the object is not stored on the client, and if any rmi call was successful, this is also a rollback.

I'm relatively new to distributed transactions, but I think I need an XA transaction using RMI calls.

I found a good link to a topic here , but does not mention a template for calling two remote method calls on different servers. I would like to hear more about the subject in terms of recommended reading, as well as any pointers on how to achieve this using spring. Does this transaction manager use for this?

Thanks.

Answer 1

Here is how this situation can be theoretically considered. First you need to have several distributed JTA transaction managers on each node. One acts as a master, the other as slaves. The wizard coordinates the commit / rollback of the distributed transaction with subordinates. There are standalone JTA implementations, for example. JOTM .

Vanilla RMI does not support the dissemination of contextual information, such as transaction transaction identifier. But I think RMI has hooks so that it can be expanded to support this. You can watch Carol .

You will need to use XAResource to wrap the participants in the transaction so that they can be credited to the distributed transaction. The master will have to send commit / rollback messages to the slaves, which the XATerminator will have to use in order to act accordingly.

The JTA specification is just a distributed transaction manager; transaction logging in the transaction log should be done by servers. A library exists to manage a transaction log, for example. Howl .

I don't think Spring can be used - even with a distributed transaction manager - to do this easily. I once tried using RMI with a distributed transaction managed by a standalone client and several subordinates. Here is about this blog . It was quite difficult.

You can get all this for free if you use the Java EE application server with IIOP. IIOP supports the distribution of distributed transactions. A client can be a client application container , and you can control transactions using UserTransaction . This is actually one of the rare cases when I think that using the application server is really justified.

But this suggests that a distributed transaction is complex things that can lead to heuristic failures, a timeout if one of the nodes dies, and complex recovery procedures.

My last piece of advice would be: try to find a construct that is not related to a distributed transaction, if possible. It will make you a lot easier.

You can breathe inspiration into the BPEL compensation mechanism . Perhaps there are other approaches to error handling and reliability that can avoid the use of distributed transactions.

Answer 2

As far as I know, Spring alone does not manage distributed transactions. It can use the JtaTransactionManager , which in turn delegates to the Java EE server transaction coordinator. Therefore, as I understand it, such transactions are only available through data sources registered in the application container.

You can try writing your own implementation of XAResource (not sure if this is the best way, but still) and registering it in the application container, but Spring won't help you with this.