What is Atomicity?




Atomicity

 We introduced the concept of an atomic transaction, which is a program unit that must be executed atomically. That is, either all the operations associated with it are executed to completion, or none are performed. When we are dealing with a distributed system, ensuring the atomicity of a transaction becomes much more complicated than in a centralized system. This difficulty occurs because several sites may be participating in the execution of a single transaction.

 The failure of one of these sites, or the failure of a communication link connecting the sites, may result in erroneous computations. Ensuring that the execution of transactions in the distributed system preserves atomicity is the function of the transaction coordinator.

 Each site has its own local transaction coordinator, which is responsible for coordinating the execution of all the transactions initiated at that site. For each such transaction, the coordinator is responsible for the following:

Topics You May Be Interested In
Layered Architecture Of Operating System Log-structured File Systems
Direct Memory Access Design Issues
Operating System Operations- Dual-mode Operation, Timer System And Network Threats
User Os Interface, Command Interpreter, And Graphical User Interfaces What Is The Security Problem?
Disk Attachment Features Of Real-time Kernels

• Starting the execution of the transaction

• Breaking the transaction into a number of subtransactions and distributing these subtransactions to the appropriate sites for execution

• Coordinating the termination of the transaction, which may result in the transactions being committed at all sites or aborted at all sites We assume that each local site maintains a log for recovery purposes.

What is Atomicity?

Topics You May Be Interested In
Operating System Structure Atlas
File Access Methods Disk Scheduling In Multimedia Systems
Directory Implementation What Is Multics?
System And Network Threats The Mach Operating System
Afs - Andrew File System Mutual Exclusion

The Two-Phase Commit Protocol

For atomicity to be ensured, all the sites in which a transaction T has executed must agree on the final outcome of the execution. T must either commit at all sites, or it must abort at all sites. To ensure this property, the transaction coordinator of T must execute a commit protocol. Among the simplest and most widely used commit protocols is the two-phase commit (2PC) protocol, which we discuss next. Let Tbe a transaction initiated at site S,, and let the transaction coordinator at Si be C,. When T completes its execution—that is, when all the sites at which T has executed inform C; that T has completed—then C; starts the 2PC protocol.

• Phase 1. C; adds the record to the log and forces the record onto stable storage. It then sends a prepare (T) message to all the sites at which T has executed. On receiving the message, the transaction manager at that site determines whether it is willing to commit its portion of T. If the answer is no, it adds a record to the log, and then it responds by sending an abort (T) message to C,. If the answer is yes, it adds a record to the log and forces all the log records corresponding to T onto stable storage. The transaction manager then replies with a ready (T) message to C,.

 

Topics You May Be Interested In
Instruction Execution Robustness
Multithreading Models I/o Performance
Virtual Machines Structure Of Page Table
Stable Storage Implementation What Is Election Algorithms ?
File Access Methods Distributed System

 

 • Phase 2. When C, has received responses to the prepare (T) message from all the sites, or when a pre-specified interval of time has elapsed since the prepare (T) message was sent out, C, can determine whether the transaction T can be committed or aborted. Transaction T can be committed if <£,- has="" received="" a="" ready="">< commit T> or a record < abort T> is added to the log and is forced onto stable storage. At this point, the fate of the transaction has been sealed. Following this, the coordinator sends either a commit (T) or an abort (T) message to all participating sites. When a site receives that message, it records the message in the log. A site at which T has executed can unconditionally abort T at any time prior to its sending the message ready (T) to the coordinator. The ready (T) message is, in effect, a promise by a site to follow the coordinator's order to commit T or to abort T.