--- In [email protected], "Zubin Wadia" <[EMAIL PROTECTED]> wrote: > > 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. >
Zubin, Thanks for this detailed explanation. Sumit
