Why should we avoid distributed transactions ?

A distributed transaction is a transaction that spans multiple resources. A distributed transactions are also at times referred to as XA transactions. XA transaction is X/Open group specification on distributed transactions. XA transaction is required to guarantee the ACID (Atomicity,Consistency,Isolation,Durability) properties of a transaction when the transaction spans multiple resources - be it multiple databases,database and JMS connection, database and file system or any resource. XA transactions require transaction manager to co-ordinate the multiple resource managers involved in the transaction. Transaction Managers co-ordinate the resource managers involved using 2-Phase Commit protocol (2-PC).
Usage of distributed/XA transactions in turn come with its own issues and complexities.Some of the problems/complexities with distributed transactions include

1. 2-PC protocol is very chatty protocol and does a lot of logging to be able to recover from any failure scenario.
2. Too much overhead to 99.9% of the cases to handle less than 0.1% of the failure/exception cases
   
3. Increases the amount of time the locks are held on the databases. This increases the chances for deadlocks on the database. This also lowers the overall performance of the system.
4. Distributed transactions are sort of the bane of scalability. It sort of grinds the entire system to halt by adding overhead to each and every transaction.
   
5. Availability of the Systems goes down. When using distributed transactions,the completion of a distributed transaction is now a product of the availability of two different systems and there by the the total availability of the system goes down.
6. XA/Distributed transaction configuration is complicated and is difficult to test to make sure the configuration is configured correctly. (Many Java Developers tend to believe that using JTA implementation of transaction manager will take care of a XA transactions and tend to forget configuring the resources as XA resources. Many a time people end up using JTA even while dealing with single resource. ). Many people get XA enlisted resources when they don't have to and many a time the applications would perform better if they weren't unnecessarily using XA.
   
   Based on the various issues mentioned above it is very much recommended that the use of XA transactions be avoided as much as we can. So how do we maintain the ACID of a transaction that goes against multiple resources !!!? In most cases intelligent recovery business scenarios supported by the system's management interface will eliminate a need for XA. The possible ways to circumvent the need for distributed transactions could be a seperate post in itself...stay tuned..:).