airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thanmai <thanmai....@gmail.com>
Subject Re: Transaction Management
Date Fri, 10 Mar 2017 08:08:46 GMT
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.tilak26@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


Mime
View raw message