Introduction to the theory of nested transactions

Nancy Lynch, Michael Merritt
1986 Theoretical Computer Science  
A new formal model is presented for studying concurrency and resiliency properties for nested transactions. The model is used to state and prove correctness of a well-known locking algorithm. This paper develops the foundation for a general theory of nested transactions. We present a simple formal model for studying concurrency and resiliency in a nested environment. This model has distinct advantages over the many alternatives, the greatest of which is the unification of a subject replete with
more » ... formalisms, correctness conditions and proof techniques. The authors are presently engaged in an ambitious project to recast the substantial amount of work in nested transactions within this single intuitive framework. These pages contain the preliminary results of that project-a description of the model, and its use in stating and proving correctness conditions for two variations of a well-known algorithm of Moss [22] . The model is based on I/ 0 automata, a simple formalization of communicating automata. It is not complex-it is easily presented in a few pages, and easy to understand, given a minimal background in automata theory. Each nested transaction and data object is modelled by a separate I/O automaton. These automata, the system primitives, issue requests to and receive replies from some scheduler, which is simply another I/O automaton. Simphe syntactic constraints on the interactions of these automata ensure, for example, that no transaction requests the creation of the same child more than once. One scheduler, in this case the "serial scheduler", interacts with the transactions and objects in a particularly constrained way. The * Input Condition. For each input operation T and each state s', there exist a state s and a step (s', V, s). This condition says that an I/O automaton must be prepared to receive any input operation at any time. This condition makes intuitive sense if we think of the input operations as being triggered externally. (In this paper, this condition serves mainly as a technical convenience, but in [ZO], where infinite behavior is considered, it is critical.) An exmution of & is a finite alternating sequence so, ml, sl, r2, . . . , sk of states and operations of ~4, ending with a state. Furthermore, so is in start(&), and each triple (s', n, s) which occurs as a consecutive subsequence is a step of ti. From any execution, we can extract the schedule, which is the subsequence of the execution consisting of operations only. Because transitions to different states may have the same operation, different executions may have the same schedule. 132 lV. Lynch, M. Merritt is either an rNFoRM_coMMIT_AT(X)oF(U) operation, or eke an INFORM_AB~RT_ AT(X) for some ancestor of T. Proof. At the time the CREATE(T) occurs, the lock manager puts T into the set of lock-holders. Before the lock manager can send in CREATE( T'), it must be that all the transactions in lock-holders are ancestors of T'. There are only two ways in which this can happen. One possibility is that the lock manager first receives INFORM-COMMITS for all ancestors of T up to lca( T, T'), including INFORM-COM- MIT_AT(X)OF( U). The other possibility is that the lock manager first receives an INFORM-ABORT for an ancestor of T. cl The concurrent con troller The concurrent controller is similar to the serial scheduler, but it allows siblings to proceed concurrently. In order to manage this properly, it interacts with "concurrent objects" (lock managers and resilient objects) instead of just basic objects. The operations are as follows. Input operations : REQIJEST_CREATE( T), REQUEST_COMMIT( T, Z?). Output operations: CREATE(T), T a non-access transaction, INTERNAL_CREATE( T), T an access transaction, COMMIT( T, V), ABORT(T), INFORM,COMMIT_AT(X)OF( T), INFORM,ABORT_AT(X)OE( T). Each state s of the concurrent controller consists of five sets: create-requested(s), created(s), commit_requested( s), committed(s), and aborted(s). The set commit-requested(s) is a set of (transaction, value) pairs, and the others are sets of transactions. (As before, we will occasionally write T E commit_requested( s) for ( T, u) E commit-requested(s) for some v.) All sets are initially empty except for create-requested, which is { To}. Define returned(s) = committed(s) u aborted(s). The operations are as follows. REQUEST_CREATE( T) Postcondition : create_requested( s) = create_requested( s') u { T}. REQUEST_COMMIT( T, V) Postcondition : commit_requested( s) = co Lemma 67. Let ar be a weak concurrent schedule, and let T and T' be transactions which are not orphans in QC. Let T"= lca( T, T'). Let p = visible( Qc, T) -visible( cy, T') andp'= visible( a, T') -visible( a, T"). 73en no resilient object has operations in both @ and p'. Proof. The result is trivial if T is an ancestor of T' or vice versa, so assume the contrary. Then T' is neither T nor T'. Let R(X) be a resilient object such that both p and p' contain operations of (X). Thus, there are two accesses to X, U and V, such that operation n of U and operation 4 of V occur in p and p' respectively. Then U is visible to T, V is visible to T', but neither U nor V is visible to T", in a. It follows that U is not visible ?o T' and V is not visible to T in cy. In particular, U f V. By well-formedness, we can assume without loss of generalit) lat w = CREATE( U) REATE( V). We can also assume without loss of generality that n precedes nce T and T' are not orphans in LY, Lemma 65 implies that U and V are not orphans in cy. Then ma 59 implies that U is visible to V in (Y. But then U is visible to T' in a, a contradiction. 0 current systems In this section, we prove the main results of this paper: that concurrent schedules are seria,lly correct, and that weak concurrent schedules are correct at TO.
doi:10.1016/0304-3975(86)90014-9 fatcat:67achg4hq5g3lgiderswxxwfkm