Hi Sumit, Distributed Transactions is a vast topic that takes many years to master yet is an essential part of a programmer's toolkit.
A transaction can be XA-style where it is multiple Instances/Schemas executing transactions inside a single boundary. Or it can be across two different systems - where transaction state from one system needs to be propagated to the other for a secondary dependent decision. XA is the more "controllable" of the two because when you are using the native DB transaction manager, it can give you much more control over the transaction behavior. When you go across systems, it is much more complex and the error handling and detail is reduced significantly. So if you get into trouble, debugging will be harder. Choose the approach wisely... there are many situations where it may appear that DT is needed, but with good compensation mechanisms, consistency can still be achieved reliably. >>>>>>>>>>>>>>>>>>>> You can also do DT at the method/function level. A DT does not HAVE to involve a DB. It can be across file-systems, it can be across web service interfaces. The key is to understand when you need it and the general patterns for implementation. >>>>>>>>>>>>>>>>>>>> My favorite transaction management factory right now in the Java world is Spring. The current Spring 2.0 transaction manager factory is even more flexible than EJB3.0 in the sense that you can "chain" transactions in a nested fashion, which allows you to execute a DT within a DT, the result of which may or may not have a dependency on the other. For PHP and Perl - I do not have exposure there, but I would be surprised if mechanisms did not exist. >>>>>>>>>>>>>>>>>>>> Hope this helps, Zubin.
