Transactions

Transaction

By transaction we mean a group of tasks which are executed together.If anything goes wrong in any one of them then outcome of the entire set is rolled back.After rollback the system returns to it’s original state i.e. the state before execution of transaction started.Changes are only committed if all the tasks are completed without any problem or failure.

ACID Properties

1. Atomic – This describes the all or nothing feature of transaction.For example a transaction in document upload may contain two steps saving the file in server disk and inserting a record for the document in database.Here the transaction will be successful if both file and database record is successfully saved,if there is a problem in any one operation none will be saved.
2. Consistent- Transaction should always leave the system in consistent state.Think of the above example if the database record is saved and file is not then the system would have become inconsistent having metadata for document whose actual file is missing.
3. Isolated-Transactions has to operate in isolation until they are complete.For example when the file is not saved yet,database record for document is saved and it is visible to other users in document list screen.Other user might click that link to find that no file is attached and it will appear like a phantom record.
4. Durable-No information should be lost even if the machine goes down when a transaction is executing.

Distributed Transactions

A transaction when involves multiple persistent resources(e.g. databases) or spans across process/machine boundary is referred to as a distributed transaction.

Transaction Management

Transaction Management is neccessary to maintain the ACID properties of the distributed transaction.The two key components  of transaction management are:

1. Transaction Manager – A transaction manager manages commit/abort and monitors status of each task by coordinating with the corresponding resource managers.
2. Resource Manager – A resource manages state of a particular resource based on the instructions from the transaction manager.
   • Durable Resource Manager – Manages persistent resource
   • Volatile Resource Manager – Manages in-memory resource

Two Phase Commit(2PC) Protocol

Phase 1

• Coordinator asks each of the resource managers to commit
• Each resource manager responds whether they are about to commit or abort.
• Coordinator collects the responses and decides whether to commit/rollback the transaction as a whole.

Phase2

• Coordinator informs the resource manager it’s decision to commit/rollback
• Resource managers acknolwdges the message to commit/rollback
• Coordinator waits for acknowledgement of the resource managers

In a distributed transaction spanning across multiple server each server has  a local transaction manager and all resource managers in that server enlists with that local transaction manager.The local transaction managers in turn communicate with each other.There is superior/subordinate relationship  between each local transaction manager and the corresponding resource managers in that box.The local transaction manager of the server where the transaction is initiated is called root transaction manager or the global commit coordinator.So this is the root of the commit tree and the enlisted resource managers and other local transaction managers are it’s children.Each resource manager depends on it’s local transaction manager for commit/abort decision and each local transaction manager depends upon it’s superior transaction manager (if any) for the commit/abort decision.

The transaction manager maintains a log on disk. The log is a sequential file with transaction events. The transaction manager records transaction starts, enlistments, and commit decisions in the log. During normal processing, the transaction manager only writes to the log. However, if the transaction manager fails, it reads the log when it restarts to reconstruct the most recent state, using the log to make its state durable.