airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sneha Tilak <>
Subject Transaction Management
Date Fri, 10 Mar 2017 08:03:26 GMT
Hello dev,

Earlier we saw a Transaction Management implementation using an
event-driven approach. More details can be found on Event Driven Approach
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

In this mail, I am addressing the issue regarding the communication between
the transaction manager and services, raised by Ajinkya. (Issue

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 <>)

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.

Sneha Tilak

View raw message