Hi dev, There are a few Transaction Manager implementations: Atomikos Bitronix JTA also has a standalone Transaction Manager
Supreeth and I are looking into few implementations of Transaction Managers, mainly Bitronix as it is open source. Thanks, Thanmai > On 10-Mar-2017, at 3:03 AM, Sneha Tilak <sneha.tila...@gmail.com> wrote: > > Hello dev, > > Earlier we saw a Transaction Management implementation using an event-driven > approach. More details can be found on Event Driven Approach Wiki > <https://github.com/airavata-courses/spring17-microservice-data-management/wiki/An-Event-Driven-Architecture-Explained>. > We have tried to delve into the two-phase commit protocol to solve the same > problem. More details can be found on 2PC Protocol Approach > <https://github.com/airavata-courses/spring17-microservice-data-management/wiki/Two-Phase-Commit-Explained>. > > In this mail, I am addressing the issue regarding the communication between > the transaction manager and services, raised by Ajinkya. (Issue > <https://github.com/airavata-courses/spring17-microservice-data-management/issues/2>) > > For Distributed Transaction Processing (DTP), we can use XA (eXtended > Architecture) Protocol. It is supported by many databases and transaction > managers. XA transactions can be used with many frameworks such as Spring > Framework. (Resource <https://en.wikipedia.org/wiki/X/Open_XA>) > > Every XA transaction will need a global transaction ID as well as a local > transaction ID (xid) for each of the services (XA resources). Each of the > service is enlisted to the transaction manager by a method, begin(xid). This > tells the manager that the service is involved in the transaction and is > prepared for operations. As explained in the Wiki, the first phase is the > Commit Request phase. For this, the manager calls a method, prepare(xid). > This method expects the service's vote (as either OK or ABORT). Depending on > the reply, the manager decides whether to call commit(xid) or rollback(xid) > for statuses OK and ABORT respectively. In the end, the manager calls the > end(xid) method to tell the service that the transaction has been completed. > > Of course, there are failures that can occur. But the XA Protocol executes > some recovery operations. The first kind of failure can occur before the > protocol begins. For this, the system need not perform any operations or > rollbacks. The next kind of failure can occur during the commit request phase > and can be rectified timeout enabled rollbacks. The last kind of failure can > occur during the commit phase due to an incomplete rollback at any of the > services' ends. > > P.S. - The method names may vary depending on the transaction manager used. > > The transaction manager calls a recovery method for each of the services > facing failures. The services then trace their logs and try to rebuild to > their latest stable state. The manager then calls the required rollback > operations. In some very rare cases, the logs itself can be damaged or > corrupted. During such cases, the > manager follows some heuristics to solve the problem. > > There are many Transaction Managers that we can consider depending on the > language support and type of services. Thanmai and Supreeth are looking into > the options. > > Thanks, > Sneha Tilak
