Nested and Distributed Transactions
Nested Transaction: A nested transaction is a type of transaction where a transaction can call other sub-transactions or child transactions. These sub-transactions themselves can commit or abort independently of the parent transaction, but the final decision (commit or abort) is determined by the parent transaction. Nested transactions are useful in situations where a large task can be divided into smaller, independent sub-tasks. The parent transaction ensures that all sub-transactions either commit successfully or roll back if any of them fail. Example: A bank transfer between two accounts can be seen as a parent transaction. Each sub-transaction can represent individual steps, such as debit from Account A, credit to Account B, and update the transaction log. If any sub-transaction fails, the entire parent transaction is aborted.
Distributed Transaction: A distributed transaction involves a set of operations that occur on multiple databases or systems that may be geographically separated. These transactions are coordinated across multiple locations and must adhere to the ACID properties (Atomicity, Consistency, Isolation, Durability) to ensure correctness. Distributed transactions use protocols like Two-Phase Commit (2PC) to ensure that all parts of the transaction either commit or roll back, even if the databases are distributed across different machines. Example: When making an online purchase, the payment system and inventory system may be managed by different databases. A distributed transaction ensures that both systems are updated correctly, either committing both the payment and inventory updates or rolling back both operations in case of an error.
2PL (Two-Phase Locking) and Strict 2PL Schedule
Two-Phase Locking (2PL) is a concurrency control protocol used to ensure serializability in database transactions. It works by ensuring that all locks are acquired in the “growing phase” and are only released in the “shrinking phase.” Once a transaction releases any lock, it cannot acquire any more locks.
- Growing Phase: A transaction can acquire locks, but it cannot release them.
- Shrinking Phase: A transaction can release locks, but it cannot acquire any more.
A Strict 2PL is a more restrictive version where a transaction holds all its locks until it commits or aborts, preventing other transactions from accessing locked data even after the transaction is finished.
Example of 2PL Schedule
Let’s assume there are two transactions, T1 and T2, and two data items X and Y.
- T1 performs operations on X and Y.
- T2 performs operations on X and Y as well.
The sequence of actions for T1 and T2 could look like this:
- T1 acquires a lock on X.
- T2 waits for the lock on X (since T1 holds it).
- T1 releases the lock on X.
- T2 acquires the lock on X and proceeds.
- T2 acquires a lock on Y.
- T1 acquires the lock on Y.
- T1 releases the lock on Y after completing the task.
- T2 releases all locks after completing the task.
Here, both transactions follow 2PL by acquiring all necessary locks before releasing any.
Example of Strict 2PL Schedule
In Strict 2PL, the locks are held by a transaction until it commits or aborts. The schedule for T1 and T2 might look like this:
- T1 acquires a lock on X.
- T1 acquires a lock on Y.
- T1 performs its operations and releases both locks on X and Y only after it commits.
- T2 waits until T1 commits, then acquires the lock on X and Y.
- T2 performs its operations and releases both locks after committing.
Strict 2PL ensures that no transaction reads data until the previous transaction has fully committed, guaranteeing that all locks are held until the transaction is complete.
Comparison: Centralized 2PL vs Distributed 2PL
Both Centralized 2PL and Distributed 2PL are used to manage locks in a distributed system, but they differ in the way locks are managed and coordinated.
Centralized 2PL:
- Single Coordinator: In Centralized 2PL, a single coordinator (a central server or manager) is responsible for managing the locks for all transactions.
- Lock Management: All transactions request locks from the central coordinator. The coordinator handles lock granting, ensuring that the transactions follow the two-phase locking protocol.
- Advantages: It is simpler to implement because there is only one central manager.
- Disadvantages: It can become a bottleneck if many transactions are trying to acquire locks simultaneously. A failure in the central coordinator can lead to the failure of the entire system.
Example: In a centralized system, a bank’s central database can act as the coordinator. All transactions, such as money transfers, request locks from this database, and the system ensures proper concurrency control through 2PL.
Distributed 2PL:
- Multiple Coordinators: In Distributed 2PL, lock management is distributed across multiple sites or servers, each managing a part of the system.
- Lock Management: Each server (or site) controls locks for the data it manages, and transactions are coordinated across different sites. A distributed deadlock detection system is often needed, as multiple sites can be involved in deadlock situations.
- Advantages: It is more scalable and fault-tolerant since it does not rely on a single central server.
- Disadvantages: It is more complex to implement because it requires coordination between multiple sites and systems. Deadlock detection and resolution can also become more difficult.
Example: In a distributed e-commerce system, different warehouses and payment systems may each manage their data. Each system controls its own locks, and a distributed system ensures that transactions can still be coordinated across different systems.
Thus, Nested Transactions allow transactions to have sub-transactions, which can commit or abort independently, while Distributed Transactions involve operations on multiple, geographically separated databases. 2PL (Two-Phase Locking) ensures transactions follow a protocol of acquiring locks before releasing them, and Strict 2PL adds the restriction of holding all locks until a transaction commits. Centralized 2PL uses a single coordinator for lock management, while Distributed 2PL involves multiple coordinators spread across different sites.