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
