Write any four rules for committing the nested transaction?
Answers
Nested Transactions
The nested transaction programming model addresses the transaction composability problem by capturing the program-subprogram structure of an application within the transaction structure itself. In nested transactions, each transaction can have subtransactions. For example, the PayLoanFromChecking transaction can have two subtransactions DebitChecking and PayLoan.
Like ordinary “flat” (i.e., non-nested) transactions, subtransactions are bracketed by the Start, Commit, and Abort operations. In fact, the programs of Figure 2.1 and Figure 2.2 could be a nested transaction. What is different about nested transactions is not the bracketing operations—it’s their semantics. They behave as follows:
1.
If a program is already executing inside a transaction and issues a Start command, then Start creates a subtransaction of its parent transaction, rather than creating a new, independent transaction. For example, if DebitChecking is called from PayLoanFromChecking, the Start in DebitChecking starts a subtransaction.
2.
If a program is not already executing inside a transaction and issues a Start command, then Start creates a new, independent transaction, called a top-level transaction, which is not a subtransaction of another transaction. For example, Start in PayLoanFromChecking creates a top-level transaction.
3.
The Commit and Abort operations executed by a top-level transaction have their usual semantics. That is, Commit permanently installs the transaction’s updates and allows them to be read by other transactions. Abort undoes all the transaction’s updates. For example, Commit and Abort in PayLoanFromChecking have these effects.
4.
If a subtransaction S aborts, then all the operations of S are undone. This includes all the subtransactions of S. However, the abort does not cause the abort of S’s parent. The parent is simply notified that its child subtransaction aborted. For example, Abort in DebitChecking aborts the subtransaction, but not its parent transaction that was started by PayLoanFromChecking.
5.
While a subtransaction is executing, data items that it has updated are isolated and hence not visible to other transactions and subtransactions (just like the flat transaction model). For example, if PayLoanFromChecking executed its subtransactions DebitChecking and PayLoan concurrently and those subtransactions read and wrote some shared data (which they don’t in this example), then DebitChecking would not see PayLoan’s updates until after PayLoan commits, and PayLoan would not see DebitChecking’s updates until after DebitChecking commits.