Difference between JtaTransactionManager and ChainedTransactionManager ?

Question

I need to manage the multiple resources in my application like jms and database

While looking at transaction managers which can mange multiple resources i came across 2 transaction managers JtaTransactionManager and ChainedTransactionManager which almost claims they can manage multiple resources.

Can anyone explains whats major difference in them ? and when should i use which one?

Answer 1

As documentation says: ChainedTransactionManger doc:

PlatformTransactionManager implementation that orchestrates transaction creation, commits and rollbacks to a list of delegates. Using this implementation assumes that errors causing a transaction rollback will usually happen before the transaction completion or during the commit of the most inner PlatformTransactionManager. The configured instances will start transactions in the order given and commit/rollback in reverse order, which means the PlatformTransactionManager most likely to break the transaction should be the last in the list configured. A PlatformTransactionManager throwing an exception during commit will automatically cause the remaining transaction managers to roll back instead of committing.

This means you can create a ChainedTransactionManager by passing to it several transactionmanager. If an exception will occur to one transaction manger a rollback will be generated for all the transaction managers in the inverse order they are specified

JtaTransactionManager doc:

PlatformTransactionManager implementation for JTA, delegating to a backend JTA provider. This is typically used to delegate to a Java EE server's transaction coordinator, but may also be configured with a local JTA provider which is embedded within the application. This transaction manager is appropriate for handling distributed transactions, i.e. transactions that span multiple resources, and for controlling transactions on application server resources (e.g. JDBC DataSources available in JNDI) in general. For a single JDBC DataSource, DataSourceTransactionManager is perfectly sufficient, and for accessing a single resource with Hibernate (including transactional cache), HibernateTransactionManager is appropriate, for example.

You can use this transaction manager for managing distributed transactions for several resources

Answer 2

Both transaction managers are suitable for using with multiple resources however JTA transaction manager provides a strict guarantee that it will either commit all or none of the resources. It achieves it with 2PC (two phase commit) using XA protocol. Since it is a complicated method of keeping resources in sync it comes at cost of performance.

On the contrary ChainedTransactionManager doesn't use 2PC and XA, it is more just a way to declare that multiple resources should be committed or rolled back together and in a specific (reversed) order. Like JTA transaction manager it tries to either commit or rollback all resources together but it just doesn't guarantee that (all commit or all rollback). However in specific cases it is perfectly fine. Suppose that two resources are used with a chained transaction manager: JMS-related and DB-related so that during transaction you first read a message from a queue then process some business logic involving DB and finally commit both resources. If DB is committed first and JMS second then it is possible that DB commits but JMS rolls back. In that case initial message will be left in message queue which is not completely ok and potentially can cause a duplicated message processing (since the message was already processed and caused successful DB commit). However if your business logic is prepared for that you can handle that situation - of course at cost of additional code implementing that. However if performance is more important it is a reasonable deal as ChainedTransactionManager should perform much faster than JTA.

NB. The order of transaction managers used with ChainedTransactionManager is important: the transaction manager most likely to break the transaction should be the last in the list configured.

The bottom line. If you can safely handle a situation that one resource commits and another rolls back or this situation occurs rarely so you can neglect it then you can try using ChainedTransactionManager first. If performance is not so important and/or you want to ensure absolutely that multiple resources are in sync then probably you should use JTA.