How Transactions Work

An overview of how transactions work in high-level terms.

Posted on July 12, 2013 by Ernesto Garbarino

Overview

At an abstract level, a transaction is a formal exchange between computer systems. The formality in it implies that there is an expectation of “success” which is defined in pre-agreed terms. The most typical transaction scenarios are as follows:

Communication Transaction

A communication transaction boils down to guarantees of dispatch and arrival:

Guarantee of dispatch

This is the confirmation that the message has left the intended system boundary and is heading towards its destination. Most default asynchronous One-Way MEP consumer-side stacks have an internal queue; thus, when a message is “sent” it does not mean that it has left the consumer’s system boundary. This means that a troubleshooting process looking into “why a message has not arrived” may involve looking both at the provider-side and consumer-side queues.

Guarantee of arrival

This is the confirmation that the intended provider has received the message. All MEPs offer the possibility of verifying arrival except for the strict Asynchronous One-Way MEP. Such a possibility does not imply that arrival verification is automatic—it must be implemented.

State-modifying Transaction

A state-modifying transaction is one that may potentially change the state of one or more entities. In turn, in a distributed environment, such a state change may be triggered by means of a communication transaction, and each entity may be encapsulated by one or more services.

ACID Transaction

An ACID Transaction in the context of a service invocation has the following properties:

Two-Phase Commit (2PC)

This is a transactional mechanism used when data storage can be safely coordinated by a software system.

In a distributed system, implementing a genuine 2PC system is more difficult than in the RDBMS world because the state-modifying participants may unexpectedly become unavailable during a transaction, leaving the transaction provider in a non-final state for an undefined period of time. The WS-Atomic Transaction specification attempts to cover this scenario, although it could be argued that it rather provides a compensation protocol.

This is an oversimplified summary of the life-cycle states applicable to the transaction provider implementing the 2PC protocol, barring the event of the provider and back-ends becoming unavailable:

State Next States Description
Ready Preparing Waiting to get active.
Preparing Aborting, Committing Asking back-ends to prepare—abort if one or more back-ends aren’t ready.
Aborting Ready Asking back-ends to release resources.
Committing Rolling-back, Ready Asking back-ends to commit changes—roll back if one or more back ends cannot commit.
Rolling back Ready Asking back-ends to reverse changes.

Compensation

Compensation is a loose transactional mechanism that relies on setting former values on back-end systems as opposed to executing a rollback as is the case in in the RDBMS 2PC protocol. Compensation is, in reality, the only feasible way to try to emulate ACID properties in a distributed environment since a straight-forward rollback—as intended in the RDBMS world—cannot be applied to heterogeneous systems in a systematic fashion.