SKR 5302: Advanced Distributed Computing

7.5. Nested transactions

Allowing transactions to be composed of other transactions. 

A subtransaction appears atomic to its parent with respect to transaction failures and concurrent access.

Subtransactions at the same level, can run concurrently, but their access to common objects is serialized. 

When a subtransaction aborts, the parent transaction can sometimes choose an alternative subtransaction to complete its task. 

Main advantages

• Subtransactions at one level (and their descendants) may run concurrently with other subtransactions at the same level in the hierarchy. 
  • Allow additional concurrency in a transaction
• Subtransactions can commit or abort independently. 

The rules of committing nested transactions

• A transaction may commit or abort only after its child transactions have completed.
• When a subtransaction completes, it makes an independent decision either to commit provisionally or to abort. Its decision to abort is final.
• When a parent aborts, all of its subtransactions are aborted. 
• When a subtransaction aborts, the parent can decide whether to abort or not. 
• If the top-level transaction commits, then all of the subtransactions that have provisionally committed can commit too, provided that none of their ancestors has aborted. The effects of a subtransation are not permanent until the top-level transaction commits. 

CORBA Object Transaction Service supports both flat and nested transactions.

Nested transactions are useful in distributed systems because child transactions may be run concurrently in different servers.

Figure 13: Nested transactions