Transaction Management

[Sneha Tilak <sn...@gmail.com>]

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

Re: Transaction Management

[Thanmai <th...@gmail.com>]

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 <sn...@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