transaction decomposition using transaction semantics

Distributed and Parallel Databases, 4, 25-47 (1996) @ 1996 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Transaction Decomposition Using Transaction Semantics

ARTHUR J. BERNSTEIN AND PHILIP M. LEWIS State University of New York at Stony Brook, Department of Computer Science, Stony Brook, NY 11794

Received July 8, 1994; Accepted March 7, 1995

Recommended by: M. Tamer iizsu

Abstract. Serializability has been widely accepted as the correctness criterion for databases subject to concurrent access. However, in a number of the newer and most challenging application areas, serializable execution may not be feasible. l Serializable execution is generally implemented using a two-phase locking algorithm that locks items in the

database to delay transactions that are in danger of performing in a non-serializable fashion. Such delays are unacceptable in high performance database systems that must process hundreds, and perhaps thousands, of transactions per second and in systems supporting long-running transactions.

. In systems in which data is distributed across a federated database, a global transaction is decomposed into a set of local subtransactions executed at a subset of the sites. Serializable execution in such systems not only incurs a performance penalty, but also requires the component systems to cooperate (for example in a two phase commit protocol), with a resulting loss of site autonomy. In many applications, the component systems either can not or will not agree to the required cooperation.

A number of models have recently been proposed in which transactions are decomposed into smaller, atomic, interleavable steps. These models have the potential for improving performance since locks are released at the end of each step. Models of distributed transactions have also been proposed with the similarity that subtransactions correspond to steps. In most of this work serializability is no longer guaranteed.

In this paper we propose a new, application-oriented, correctness criterion that utilizes transaction semantics. We treat transactions as programs whose semantics can be analyzed at design time. The effect of each transaction is specified using pre- and postconditions, and any schedule that preserves these conditions is permissible. Such schedules can produce database states that could not be reached by any serial execution. In addressing the issue of performance, we use transaction semantics to decompose transactions into steps and describe a concurrency control that controls step interleaving in such a way that assertions are preserved. The same model can be used to study the interleaving of subtransactions of concurrent distributed transactions.

Keywords: non-serializable execution, transaction decomposition, transaction semantics, concurrency control

1. Introduction

Serializability has been widely accepted as the correctness criterion for databases subject to concurrent access. It generally implies the use of a two-phase locking protocol in which transactions hold locks until all needed locks have been obtained. Furthermore, to avoid cascaded aborts, locks are held until commit time (strict two-phase locking). Such concurrency controls may require transactions to hold locks for long periods and are thus inappropriate for systems supporting high-throughput, low-latency, or long-running transactions.

Several investigators have proposed transaction models inyhich transactions are decomposed into atomic steps that can be interleaved at run time. Such, models no longer impose serializability as the correctness criterion. The set of schedules they permit is larger than

26 BERNSTEIN AND LEWIS

the set of serializable schedules. Hence, they have the potential for improving performance, since locks acquired during the execution of a step are released when the step completes, thus reducing waiting. Unfortunately, most of these models do not address the problem of what criteria are to be used in doing the decomposition and how they relate to the concept of a correct schedule.

Our research complements this work. Our contribution is an exploration of transaction semantics as a theoretical foundation for systems that decompose transactions into steps. Specifically, we use transaction semantics to (1) define a new correctness criterion, (2) guide transaction decomposition, (3) determine the step interleavings that preserve correctness, and (4) serve as the basis of a new concurrency control that allows only these interleavings at run time. We assume that transactions are programs whose semantics can be analyzed at design time. The analysis yields a proof of each transaction, containing assertions that must be true of the database state as the execution of the transaction progresses. The effect of each transaction is specified using pre- and postconditions, and any schedule that preserves these assertions is correct. The requirement of serializability is thus relaxed.

For example, consider a,simplified model of a stock market buy transaction. The database contains a “book” containing sell offers for each stock. Suppose a buy transaction for n shares has the postcondition that it bought n shares and no cheaper shares remain in the book, and we can prove that a particular implementation of that transaction satisfies this postcondition. Then in any serializable execution of two such transactions not only will the postconditions of the two transactions be satisfied in the final state, but all shares acquired by the first in the serialization order will have been purchased at a price less than or equal to those acquired by the second. Now suppose that ‘each buy transaction is decomposed into interleavable steps, such that each step buys n’ shares, n’ ( n, and the postcondition of each step is that it bought n’ shares and no cheaper shares remain in the book. Then, in any execution in which the two transactions’ steps are arbitrarily interleaved, the postconditions of the two transactions will again be satisfied in the final state. In this case, the shares purchased by one transaction will not necessarily be uniformly greater than or less than the other, but since that is not required in the transaction’s postcondition, the transactions can be executed in a non-serializable fashion.

Note that it would be possible to make each step a separate short transaction, which separately commits. However, by grouping all steps into a single transaction we gain the advantages of being able to

1. pass information from one step to another through variables local to the transaction, 2. make assumptions about the state of the database in one step of the transaction as the

result of operations executed in prior steps, and 3. automatically guarantee atomicity for the entire transaction.

Transactions can be quite complex, and any methodology that requires the transaction designer to generate a formal proof of each transaction can add a considerable burden to the task of building a transaction processing system. It has been argued that it is even difficult to produce a formal statement of the database consistency constraint-the predicate that defines the set of consistent database states. While some authors use the term consistency constraint to describe a rather imprecisely stated notion of database “correctness,” we use a more precise definition: the consistency constraint is the conjunction of the assumptions about the database required for the correct operation of all the transactions (more precisely the conjunction of the preconditions of all the transactions). While it may not be a simple

TRANSACTION DECOMPOSITION 27

matter to write these assumptions down, it is certainly desirable that transaction designers have them in mind when they design transactions.

Whether or not a formal proof is actually generated, however, the designer of any program, particularly a concurrent program, should at least have an informal notion of the assertions that characterize the state at certain critical points during program execution. The analysis presented here can be applied to such informal assertions and, indeed, the examples we present use a mixture of formal and informal assertions.

When transaction steps are interleaved, a transaction, TI , might see intermediate results produced by another transaction, T2. If Tz subsequently aborts, those intermediate results must be reversed using compensating steps and the computation based on them performed by Tl might be invalidated as a result. We investigate the role of transaction semantics in determining whether Ti’s results are invalidated and hence whether (1) Tz’s intermediate results should be exposed or (2) Tl’s results must be compensated for. Thus, in the stock market example, if T, buys a share that is more expensive than one bought by Tz, Tl has seen an intermediate result of T2. If Tz is subsequently rolled back, Tl ‘s postcondition is no longer satisfied.

The results presented here are applicable in other contexts. For example, a transaction over a distributed database consists of a set of subtransactions-corresponding to the steps of the previous model-executed at individual sites. If only a single site is involved, we refer to the transaction as local; otherwise it is global. The interleaved execution of concurrent global transactions might require that subtransactions be delayed in order to ensure global serializability. Such delays not only impact performance, they also imply a loss of autonomy by the individual sites:

l Even though a subtransaction has completed at a site, its locks at that site cannot be released until the corresponding global transaction has completed at all sites.

l Global serializability usually implies the use of some atomic commit protocol such as the two phase commit protocol. Such protocols typically have an “uncertain period,” after a site has voted, but before it receives a commit or abort message. Each site must agree that it will not abort its subtransaction during the uncertain period. Locks must be held during this period.

The second situation is a significantly more stringent limitation on site autonomy than the first, since in the first situation the site can abort the subtransaction; in the second situation, it cannot.

In those applications where the local database administrators are unable or unwilling to sacrifice the required autonomy, it may not be possible to use serializability as the correctness criterion. Transaction semantics can once again by used to define a new correctness criterion: any interleaving of subtransactions that preserves the assertions in the proofs of the global transactions is correct. Compensating subtransactions must be used to deal with exposed intermediate results, and a distributed concurrency control can be used to control the interleaving of subtransactions. The design of such a control is the subject of current research. While the remainder of this paper concentrates on the use of a new correctness criterion to increase the performance of a centralized database, it should be apparent that the analysis is equally applicable to distributed databases, with subtransactions replacing steps.

Finally, semantics also play a role in applications in which performance and site autonomy is not the major issue. A number of applications involve the concept of a session, which is


a sequence of predefined interactions with a user. For example, a session at an ATM might involve password verification, balance reporting, deposit/withdrawal requests, etc. Sessions are implemented within the system as a series of (programmed) transactions that correspond to the steps discussed previously. The semantics of these transactions and of the allowable sessions are crucial in the design of such a system. Thus, in a system in which password verification is implemented as a separate transaction, it is important to know whether a password is still valid when, later in a session, the user requests a withdrawal. Semantics can be used to determine how interactions with a user are translated into transactions within the system and how concurrent sessions can be interleaved.

2. Background

Considerable research has been done on the problem of building high-performance concurrency controls. In the following we confine ourselves to reviewing the research in transaction processing systems that is most closely related to the work described in this paper: (1) the use of semantics and (2) transaction decomposition.

An early use of semantics in the special case where the consistent states of the database are described by a linear inequality and database operations are linear appears in [3.5]. More generally, semantic approaches have viewed the database as a collection of abstract objects as contrasted with a collection of uninterpreted records. Whereas in the case of records two operations are said to conflict if one is a write, the semantics of abstract operations can be used to narrow the notion of a conflict [37, 15,2, 381. Serializability is generally the goal of this approach.

We are interested in using the semantics of the transaction as a whole, as contrasted with the semantics of the individual opemtions from which it is built. The semantics of a transaction can be formally described by a proof that is conveniently presented by annotating the transaction with assertions describing the state of the database at each point during its execution [16, 51. The pre- and postconditions of each transaction generally include the database consistency constraint. Some work has been done [34] on the automatic analysis of a transaction to determine if the constraint is maintained and to aid in its modification if it is not. We assume that such an analysis has been done (either automatically or by the transaction designer at design time) and therefore each transaction maintains the consistency of the database (satisfies the C property of the ACID requirements). The key issue is whether the assertions developed in the proof describe the state when transactions are executed concurrently. If so, the transactions perform correctly when execution is interleaved. If not, we say that the proofs interfere with one another [28] and hence the transactions do not behave correctly under interleaving.

Instead of using serializability as a correctness criterion for concurrent execution, this approach requires the weaker non-interference condition that guarantees only that assertions are preserved. Since an assertion generally denotes a set of states (all the states for which the assertion is true), this approach to correctness does not require that a concurrent schedule exactly mimic some serial schedule: neither the final state of the database nor the information returned by a transaction to its invoker need be identical to what would be produced by some serial schedule. Hence more flexibility, in the form of non-serializable schedules, is permitted.

In this paper we are interested in decomposing transactions into atomic, interleavable steps. Recent proposals along these lines whose goal is to preserve serializability are

TRANSACTIONDECOMPOSITION 29

[ 17, 26, 321. Most proposals, however, do not preserve serializability. A number of such proposals are described in [ 1 l] (see also [4]). An early paper that introduced issues related to decomposition using the “spheres of control” model is [9].

A major issue that arises in systems that permit non-serializable schedules is that a transaction, T, might externalize intermediate results prior to committing. Such results might affect concurrent transactions and cannot simply be rolled back if T aborts. Instead, compensation is used. Compensation is frequently ill defined in the literature, but generally implies that the “effect” of the step is reversed. In some situations, not all effects need be reversed. For example, in reversing the effect of a transaction that purchases an item in a retail store and adds the customer’s name to the store’s mailing list, the name need not be deleted from the list. Compensation is dealt with in a number of recent papers (e.g., [24, 19,23,21]).

The use of non-serializable schedules is proposed in [13]. Similar work appears in [25] and [ 121. These papers assume that transactions have been decomposed into steps and that application designers provide rules for correct step interleavings using models provided in the papers. In the approach adopted here the correctness of each transaction is specified without reference to concurrency; it is the system’s job to allow only interleavings that preserve that specification.

A Saga [ 14,8] is a long running transaction that is broken into compensatable steps. The results produced by a Saga’s (forward) steps are externalized before the Saga commits and, if the Saga aborts, compensating steps are executed. No restrictions are placed on how concurrent Sagas can be interleaved.

A number of projects incorporate the notion of decomposition, non-serializability, and compensation in a variety of ways. Examples of such work are the Cooperative Transaction Model [27], Distributed Object Management [7], the Flex Transaction model [22], and polytransactions [33]. Much of this work does not deal with the major issues of concern in this paper: (1) the relationship between acceptable schedules and transaction semantics, (2) the effect of externalized partial results and compensation on concurrently executing transactions, and (3) the properties of database states reachable during concurrent execution. Furthermore, in these projects correctness is generally defined in terms of restrictions on allowable schedules. Restrictions on the order of subtransactions in a particular transaction are generally specified. In some cases, restrictions on how transactions can be interleaved are specified as well (for example, in the Cooperative Transaction Model correct interleavings are specified using a context free grammar); such restrictions can be difficult to specify correctly when the number of transactions is large and/or the dependencies between steps complex. By contrast, in our approach the job of determining correct interleavings is left to the system.

ConTracts [36,30] can be thought of as Sagas in which a partial order of steps is specified in a control flow language. Compensating steps are used to deal with the committed steps of an aborted ConTract and serializability is not guaranteed. Semantics are introduced in the model by including entry and exit assertions to describe the global state required and produced, respectively, by a step. If an entry assertion of a step is not true when the step is to be initiated (as a result of concurrent execution), special action must be taken. A similar approach is taken in [l], although interleaving is done at the database operation level, rather than the step level. Consistency assertions are selected by the transaction designer as preconditions of the operations and are checked when the operation is invoked. By contrast, in our approach interstep assertions are derived from transaction proofs, and the


concurrency control guarantees that they will be true of the database state at the appropriate time.

An approach that uses semantics in a more formal way and admits non-serializable schedules is described in [3 11. The database is viewed as being decomposed into a collection of atomic data sets (ADS) in such a way that the set of consistent database states is the Cartesian product of the consistent states of the ADS’s. Transactions are decomposed into segments of code, called ADS segments, that access distinct ADS’s serializably. The decomposition is modular, meaning that the decomposition of one transaction is independent of all other transactions. The essential result is that a common ordering in the way ADS segments of concurrent transactions access shared ADS’s is not required. The resulting non-serializable behavior is possible because the model requires that (1) each ADS segment leave the ADS that it accesses in a consistent state and (2) assertions describing the state of the database that are preconditions or postconditions of ADS segments can be no stronger than database consistency. Condition (1) implies that the assertions mentioned in (2) are not interfered with The effect of an ADS segment is described by assertions that simply state that the value written to an ADS is some function of the values previously read by the transaction from ADS’s (such an assertion cannot be interfered with since it says nothing about the current state of database variables). A limitation of the model is that it does not deal with conditional statements.

The notion of correctness in [3 11 is closely related to the concept of predicatewise serializability [20,18]. In both cases the consistency constraint is used to decompose the database into subsets and transactions are required to be serializable (although not necessarily in the same order) in each subset. A model involving conditional statements is described in [29] where it is shown that predicatewise serializability does not ensure database consistency and additional restrictions on transactions and schedules sufficient to ensure correctness are described.

Both the work of [31] and the work using predicatewise serializability use the consistency constraint of the database to partition it into parts, but make little use of the semantics of the transactions. Instead, they rely on serializability to ensure that interleaved access to each part of the database is state equivalent to some serial execution for that part. In contrast, since the results presented here are based on transaction semantics, state equivalence can be replaced by the weaker requirement that only assertions about the state need be preserved.

The special requirements of a CAD system encourage the use of transaction semantics to determine when tasks can be executed and how integrity constraints should be maintained. An early paper on this subject is [lo]. [3] and [18] describe a nested transaction model for a CAD environment that preserves database consistency constraints but does not force executions to be serializable. They do not provide a mechanism for choosing the subtransactions.

3. Concurrency and transaction semantics

We formally characterize the semantics of a transaction, 8, with a triple of the form

111 Ti {I A Qil -cl)

where I is the consistency constraint of the database, and Qi asserts that 7;: has performed its intended function. Qi is a formal restatement of Ti’s specification supplied by the user,


and we refer to it as the transaction’s result. The triple asserts that if z is executed starting in a state in which I is true of the database and if T terminates, then I A Qi will be true of the database state on termination. If the triple correctly characterizes the transaction, we say that it is a theorem. Triples can be proven in the context of a formal system of program logic.

For example, if Z is a transaction whose purpose is to purchase 12 shares of a particular stock, Qi might assert that sell orders for IZ shares have been deleted from the database and when each share was bought, no cheaper unbought shares existed in the database. In most applications it is likely that Qi is stated in a form that cannot be interfered with (as in the above example).

By a step we mean an atomically executed unit of program text, and we assume that q is constructed from steps. Initially we can think of a step as a statement. We shall see shortly that larger units of text are more appropriate. A proof of (1) can be abbreviated by an annotated program in which each step of z, sj,k, is preceded by an assertion, pre(si,k), its precondition. The proof guarantees that if si,k is executed starting in a state in which pre(si,k) is true, the next assertion, pre(Sj,k+i), will be true in the state that exists when 8i.k terminates.

The concurrent execution of a set of transactions, t, can be described by a concurrent schedule, which is a sequence over the steps of the transactions in t. The ordering of steps in the sequence represents the equivalent serial order in which those steps are executed. A schedule is complete if all transaction in t terminate. We deal only with complete schedules in this paper, and we always assume that a schedule starts in a state in which I is true.

A concurrent schedule of a set of transactions {Tr , 75, . . . , T,} is correct if, starting in a state in which I is true, Qi is true when each transaction, 7;:, terminates and I is true of the database state when the system quiesces. Since the condition for correct concurrent schedules is stated in terms of assertions rather than database states, some schedules may result in database states that could not have been reached in any serial schedule of the given transactions.

The major issue with respect to concurrent execution is interference: if the execution of the (atomic) statements of Ti and Tj are interleaved, pre(si,k) might not be true when si,k is executed. To demonstrate noninterference we must demonstrate, for all i and j and all statements in Ti and Ti, that the triple

{pd%,k> A pre(sj.i>) sj,l be(%,k))

is a theorem. The triple asserts that if I;: and Tj are executed concurrently and if Sj,k and Sj,l are the next statements to be executed in each (hence the preconditions of both are initially true) and if Sj.1 is executed first, then Si,k can be executed next since its precondition will still be true when the execution of sj,l completes. That is, the execution of sj,l between si,k-1 and Si,k does not result in a state in which pre(si.k) is false [28]. If the triple is not a theorem we say that the proofs interfere and, in particular, that si,l interferes with pre(&.k). We can guarantee that when sj,k is executed pre(si,k) is true if the concurrency control does not permit any step that interferes with pre(si,k) to be executed between sj,k-1 and Si,k- If pre(si,J is not interfered with by any step, then any step can be interleaved at that point.

The conventional approach to controlling the concurrent execution of transactions is to use a concurrency control algorithm, such as strict two-phase locking, which guarantees that transactions are isolated. Intermediate results of uncommitted transactions are not


externalized and hence cannot affect concurrently executing transactions. In the transaction model under investigation here, transactions are not isolated. They are decomposed into steps, which are the grain of interleaving, and intermediate results are exposed. The step decomposition described in [3 l] is done in a modular fashion. The advantage of a modular approach is that, since in decomposing one transaction no assumptions are made about the effect of steps of another transaction, the decomposition of existing transactions does not change when a new transaction is added or when an existing transaction is modified. The disadvantage is that less information is brought to bear on the decomposition process.

A non-modular approach can use information about all transactions in the decomposition of any one, and possibly produce a finer decomposition. More analysis is required in a non-modular design, but the analysis is done at design time, not run time. The finer the decomposition, the more concurrency. For example, in a modular approach, interstep assertions about the database state can be no stronger than I since there is no guarantee that a stronger assertion will not be interfered with by some step about which we have no information. In a non-modular approach the semantics of all steps are available and hence we can check for interference. Thus, interstep assertions can be stronger than I, and hence information about the database state developed in one step of a transaction can be communicated to another. In [31] if such communication is required, the two steps must be coalesced into a single step, and hence the granularity of decomposition is coarser. A non-modular approach has the disadvantage that whenever a new transaction is added to the system or an old transaction ismodified, the design-time analysis must be repeated. While the overall structure of the concurrency control remains the same, the introduction of new assertions and steps requires that the interference analysis must be redone. Thus a non-modular approach is appropriate when the number of distinct transactions is not large, the set is relatively stable, and concurrency must be maximized. We take these to be the characteristics of the applications we are addressing.

Our approach to decomposition is to use transaction semantics in a non-modular fashion. The decomposition is done in such a way that either interstep assertions are not interfered with (and hence any step interleaving is correct), or there is interference but a high-level concurrency control is used to guarantee that a step that interferes with pre(3i.k) is not executed between Si,k-t and Si,k. In either case schedules that are not serializable are permitted. The isolation of steps is guaranteed by a low-level concurrency control, and we assume two-phase locking for that purpose.

We start the decomposition with an annotated program for each transaction corresponding to a proof of (1) in which the steps are the individual transaction statements. If the proofs interfere, we attempt to reduce the interference by coalescing successive steps into a larger step, which executes as a single atomic unit. Coalescing is guided by two principles.

1. If pre(sj,k) is interfered with by some step in Tj 3 we consider the possibility of coalescing Si,k-l and Sj,k. since after coalescing, pre($j,k) iS n0 longer an interstep aSSertiOn

(it is an intrastep assertion), it cannot be interfered with (i.e., the low-level concurrency control guarantees that every schedule is equivalent to a serial schedule of steps and hence equivalent to a schedule in which nothing is interleaved between Si,k-1 and Si.k).

2. If S&k interferes with pre(sj,l), but the combined effect of Si,k and $&+I does not, we consider the possibility of coalescing Si,k and ~i,k+l. For example, pre(sj,l) might assert x = y, Si,k might increment x, and Si,k+t might increment y by the same amount. The


combined effect of the two steps is to bring x and y from one state that satisfies the assertion to another. Individually, each interferes with pre(si,l), but the new step formed by coalescing Sj,k and Si,k+l into a Single step does not.

Using these two principles, steps can be designed so that interference with interstep assertions is minimized. We refer to the remaining interference as residual interference. When residual interference exists, a high-level concurrency control can be used to prevent the interleaving that causes interference from occurring at run time.

The removal of interference motivates the coalescing of steps into larger steps. The more interference, the larger the step size and the less concurrency. In the limit the entire transaction becomes a single (isolated) step, there is no residual interference (and hence no need for a high-level control) and serializable schedules result. To maximize concurrency, on the other hand, we must minimize step size. Hence, the assertions used in the proofs of each transaction should be no stronger than necessary. For example, a conjunct of 1, Ik, that asserts some relationship among database variables not accessed by c need not be a precondition of q, as is implied by (1). Steps of a transaction, Tj, that interfere with 1, can be interleaved arbitrarily with the steps of z despite the fact that proofs of the form (1) of the two transactions interfere. Hence, it is important that in the process of coalescing steps, a proof of Ti involving the weakest possible assertions be used. Clearly, such a proof must demonstrate that Qi is a postcondition of the execution of q. In addition, if some step of 7;: interferes with some conjunct of I, some subsequent step of 7; must restore the database to a state in which that conjunct is true. Thus, in weakening assertions we must be sure that the resulting proof is strong enough to guarantee that each conjunct of f that is interfered with by some step of z is subsequently restored. This reasoning is made more formal in the following paragraphs.

Consider a transaction, 7;, that is decomposed into a sequence of steps, si, 1, s~,J, . . . , ~i.~, and a proof (expressed as an annotated program) of the form

i4.0) si,l {Ai,1 1 si,2 . . . Si,mi {Aimi 1 (2)

Ai,j is an interstep assertion that is a postcondition (precondition) of step Si,j (Si,j+l). The annotation expresses the fact that when ir;: is executed in isolation, A~J is true of the database state when control is between S~,J and si,j+l. Note that, although the assertions do not uniquely define the state, the proof demonstrates that they are strong enough to guarantee that the transaction’s postcondition will be true on termination, and hence the specification supplied by the user is satisfied. We assume that all assertions are in conjunctive normal form and that

where G is the number of conjuncts in I. We say that (2) is a reduced proof of Ti if

1. Ai,o is a conjunction of a subset of the conjuncts of I, 2. Ai,mi + Qi, and 3. for all j, 1 5 j F G, either

(a> ((Vk)(l 5 k 5 m) {Ai,.&1 A fj, %,k Izjf> or

(b) A,mi * zj

34 BERNSTEINANDLEWIS

Condition 1 states that the only thing we can assume initially is database consistency, and since we would like assertions to be as weak as possible, we only assume those aspects of consistency that are needed to demonstrate that Ti works correctly. Condition 2 states that when T completes its result, Qi, will be true, and hence q meets its specification. Condition 3 states that for each conjunct of I, either the precondition of each step is strong enough to support a proof demonstrating that the conjunct is invariant to the execution of that step, or if not, the conjunct is part of the postcondition of the transaction (so that if some step sets the conjunct false, some subsequent step sets it true again). Hence, Ti maintains the consistency of the database.

Note that a proof of the theorem {I} q {Z A Qi} is a reduced proof. Since we are interested in using the weakest possible assertions, we define a maximally reducedproufto be a reduced proof satisfying the additional property that any further weakening of Ai. by eliminating additional conjuncts of Z does not yield a reduced proof.

It follows from the definition of Z that

Z E A Ai,o (3)

since Ai Ai,o is the conjunction of all predicates that must be true of the database to correctly execute all transactions.

We say that a concurrent schedule is valid if it is complete and when each step is executed, its precondition in a maximally reduced proof is true of the database state. Then we have the following theorem.

THEOREM. Every valid schedule is correct.

PROOF (Contradiction). Let S be a valid schedule where S = cri , ~2, . . . , a~, and assume S is not correct. Then one of the following two cases must apply:

Case 1 Z is not true of the final database state. Then let Zi be a conjunct of I that is false in the final state, and assume that ej, where aj is a step of Tl, is the last step in S such that Zi is true of the database state that precedes the execution of that step. Since S is valid, pre(aj) is also true of the database state preceding the execution of ej. If Zi is an invariant conjunct of Tl, then it follows from condition (3a) that Zi must also be true of the database state following the execution of cj) contradicting the assumption. Suppose Zi is not an invariant conjunct of Tl. Since S is complete it must contain ~i,~, , the final step in Tl, and since S is valid, it follows from condition (3b) that Zi is true of the database state following the execution of $1 ,m,, again contradicting the assumption.

Case 2 Qi is not true when z terminates. Since S is valid, when Si,m, is executed, its precondition is true. Hence, from condition (2), Qi is true of the state following the execution of that step, contradicting the assumption. q

To guarantee that all schedules are valid, we propose to use a two-level concurrency control [38]. The lower level uses a conventional algorithm (e.g., two-phase locking, time stamp ordering) to ensure that steps are executed in isolation. The higher level, which we refer to as an assertional concurrency control, controls the set of steps that can be executing concurrently in such a way that it permits Sk.1 to be executed between Si,j and Si,j+i only if

i4.j A &,1-l I sk,l ‘iAi.jl


where the assertions are taken from the maximally reduced proofs of z and Tk. If this condition holds, Sk,/ does not interfere with Ai,j. We discuss assertional concurrency controls in a later section.

3.1. Interference-free decompositions

We consider two cases where the decomposition of each transaction into steps results in interference-free proofs. Hence, no step interferes with an interstep assertion in another transaction. Since an arbitrary interleaving of steps is allowable, an assertional concurrency control is not necessary (a lower-level concurrency control is, however, required).

3.1.1. Modular inter$erence-free decomposition. In a modular analysis the decomposition must be conservative: the steps of 7;: are chosen so that the interstep assertions in the maximally reduced proof, Ai,j, cannot be interfered with by the execution of any conceivable step of another transaction.

If we assume that z might be initiated at any time (that is, between any two steps of any transaction), then Ai,e, and hence using (3), I, must be invariant to the execution of all steps of all transactions.

Next consider a conjunct of Ai,j, for j > 0, that is not a conjunct of I. Since the analysis is modular, it must be the case that that conjunct cannot be interfered with. Hence the conjunct cannot involve database variables (which could conceivably be changed by concurrent transactions in such a way as to make the conjunct false). It can involve local variables of the transaction, and it can assert something about the value of a database variable, X, at the time some step, Si,r, r 5 j, completed (i.e., a snapshot of x). Such an assertion can be formulated in terms of an auxiliary variable to which the value of x has been assigned at the completion of ~i,~. Alternatively, the database state can be represented as a sequence (history) of all the operations performed on the database starting from some initial state, and the assertion can be stated in terms of the prefix of that sequence ending with the operations of si,r . Frequently that history of operations exists as the system log.

If these (rather strong) conditions (that Z is true between steps and that Ai,i cannot be interfered with) are met, the concurrency control can permit the steps of concurrent transactions to be arbitrarily interleaved.

In this and the next few sections we illustrate the concepts described here using an auto- mated trading system as an example. To avoid excessive detail we describe the transactions in pseudo-code and express the assertions in English. The reader interested in more detail should see [6]. The database contains a variable sell-book listing all pending sell orders and a variable credit indicating the amount of credit available to each of the L subscribers for the purchase of shares. We use as the database invariant

I SE ((Vs’sub) credit[sub] 2 0)

A sell transaction is shown in Fig. 1. It is composed of a single step and for simplicity we assume that sellers always sell a block of 100 shares at a price that is a positive integer. The result of the transaction is

Q ~(the argument offer has been entered in sellbook) (6)

BERNSTEIN AND LEWIS

T,& offer-p&e, oflernum, sub) :: begin

VI enter the argument offer in se&book

IQ AI) end

Figure 1. A sell transaction.

T&,(bXprice, b&burn, sub) :: var totulsh : integer := 0; (* number of shares purchased so far*) begin

{PI A I A (to&dAh = 0)) while (totaL& < Mnum) do

Find cheapest offer in sellbook; let its index be j; if ((credit[sub] < cost of sellbook~])

V (offer price of sellbookjj] > b&price)) then break; totalAh := totalsh + 100; credit[bub] := credit[sub] - cost of sellbookfj];

u-3 A I} end while;

(PIARIAI) end

Figure 2. A modular decomposition of a buy transaction.

A buy transaction is shown in Fig. 2. For simplicity in this and the following examples we assume that sub buys multiples of 100 shares and that there are always enough offers in sell-book to satisfy the bid of any subscriber (although they might not be at a price the subscriber is willing to pay). Each iteration of the loop purchases 100 shares and is a single step. The step begins just before the loop test and ends when the loop body completes. A sale is possible if the offering price is not greater than the bid price and if the buyer has sufficient credit. If either of these conditions is not met, the transaction terminates with a total purchase that is less than the number of shares requested, bidnum. The postconditions of some steps refer to a snapshot of sell-book or credit at the time the step terminates. We refer to the snapshot as SELLBOOK and CREDIT respectively. (Formally, SELLBOOK and CREDIT could be auxiliary variables to which the values of sell-book and credit are assigned at the end of the step.) The interstep assertion PI is given by

PI = (totalsh shares have been purchased) A(totalsh p bidnum) ~(each share purchased is no more expensive than any in the

snapshot of sellbook taken at the end of the step in which that purchase was made)

A(all purchases were made at a price not greater than bidprice) (7)


where totalsh is a running total of the number of shares purchased. RI asserts the various conditions that can cause loop exit (including the break).

RI = (total-sh p bidnum) v (cost of cheapest offer in SELLBOOK exceeds CREDIT[sub]) v (price of cheapest offer in SELLBOOK exceeds bid-price) (8)

Note that I is invariant to the loop body and that Q, PI, and RI do not refer to database variables. Hence the steps of concurrent buy and sell transactions can be interleaved. The importance of the fact that PI asserts only that each block of shares purchased was the cheapest block in sell-book at the time the purchase was made (not when the buy transaction terminated) should be noted. As a result, a sell transaction does not interfere with PI.

Since I is true between steps in a modular decomposition, one might think that such a decomposition just consists of a sequence of individual transactions arbitrarily glued together. However, information can be stored within the transaction between steps (for example, in the buy transaction the number of shares purchased so far is remembered). In this case, the only way the transaction could be decomposed into a sequence of smaller transactions is if information were passed through the caller from one transaction in the sequence to the next.

3.1.2. Non-modular interjerence-free decomposition. The goal of a non-modular interference-free decomposition is to choose the steps of each transaction, E, so that the intermediate assertions, Ai,j, are not (as contrasted with cannot be) interfered with by any step of any transaction.

As in the modular case, I is invariant to the execution of all steps (since any transaction might start between any two steps). Contrary to the restrictions in the modular case, however, an assertion, Ai,j, might include a conjunct that asserts something about the database state (as contrasted with something about the database state as it was when some step completed) that is stronger than I . For example, in a non-modular analysis of Tbuy and Tsell as shown in Figs. 1 and 2, we can determine that credit[k] is a monotonically decreasing variable and modify the conjunct of RI (8) to state that

cost of cheapest offer in SELLBOOK exceeds credit[sub]

This conjunct makes an assertion about a database variable and hence could conceivably be interfered with, but from the (nonmodular) analysis we can determine that the assertion is not interfered with by either TbUy or Tsell.

3.2. Decompositions that are not interference-free

In a non-modular decomposition of a set of transactions, some step, s~,J, in Tk might interfere with an interstep assertion, Ai,j, in Ti and, in order to maximize concurrency, we might decide not to eliminate the interference by coalescing steps. Such a situation can be detected at design time and an assertional concurrency control implemented in such a way that it does not permit Sk.1 to be interleaved between Si,j and Si.j+r .


As an example, suppose the interstep assertion, PI (7), of T& is replaced by the stronger assertion Pz

P2 = (totulsh shares have been purchased) A (totalsh 5 bid-rum) ~(each share purchased is no more expensive than any in

sellbook) A(all purchases were made at a price not greater than

bidprice) (9)

P2 is a postcondition of each loop iteration and is not interfered with by any step of Tbuy, but is interfered with by T,,ll. Hence an assertional concurrency control must not allow Tsell to be interleaved with Tbuy.

To demonstrate the utility of a maximally reduced proof, we modify the invariant so that the (new) invariant, I’, is false between certain steps. To do this we introduce the variable cost, which records the total value of all purchases made by each subscriber in all transactions, and relate cost to credit in I’.

I’ = ((Vsub)(cost[sub] + credit[sub] = C) A (credit[sub] >_ 0)) (10)

The modified buy transaction, T{“,, which updates cost, and assertions from a maximally reduced proof are shown in Fig. 3. The interstep assertions are given by

U2 z (cost[sub] + total-cost + credit[sub] = C) A (credit[sub] 1 0) (11)

T&#&Lpice, biidnum, sub) :: var totalsh, totaLcost, : integer := 0,O; begin

{Pz A I:, A (totalsh = 0) A (totaz.Eost = 0)) while (totaL& < &hum) do

Find cheapest offer insellbook; let its index bej; if ((me&[sua] < cost of seZZJook[j])

V (offer price of seZZbook[j] > bidqrrice)) then break; totalsh := totalsh + 100; totaLcost := total-cost + cost of sellbooklj]; medit[sub] := credit[.d] - cost of seZLbook[j];

(P2 A U2) end while;

(PZA U~AR,)

cost[dJ] := cost[subj +totaz~ost;

(J's A RB A IL) end

Figure 3. A nonmodular decomposition of a buy transaction in which the database invariant is not implied by all interstep assertions.


where total-cost is the cost of the shares purchased so far in the transaction and

R2 = (totalsh > bidnum) v (cost of cheapest offer in sellbook exceeds credit[sub]) v (price of cheapest offer in sell-book exceeds bid-price) (12)

P3 = (totalsh shares have been purchased) A (totalsh 5 bidnum) ~(each share purchased is no more expensive than any

in SELLBOOK) ~(a11 purchases were made at a price not greater than

bid-price) (13) R3 = (totalsh > bidnum)

v (cost of cheapest offer in SELLBOOK exceeds CREDIT[sub]) v (price of cheapest offer in SELLBOOK exceeds bid-price) (14)

and we have introduced a final step to update cost. Steps are separated by an empty line in this and subsequent figures.

The loop body of Tdu, (in particular, the assignment statement that decrements credit[sub]) interferes with I’. Hence, a non-modular analysis based on a proof of TL,,, in which I’ is a precondition would conclude that buy transactions (whether or not they were executed for the same subscriber) could not be interleaved with each other. However, a maximally reduced proof for a buy transaction invoked by subscriber sub does not require in its precondition all conjuncts of I’, only the conjunct I& given by

Ziu,, = (cost[sub] + credit[sub] = C) A (credit[sub] 2 0) (13

Hence, using a maximally reduced proof, it becomes apparent that buy transactions for different subscribers do not interfere. Note that buy transactions for the same subscriber interfere and hence, by this analysis, cannot be executed concurrently. We return to this point in a later section.

3.2.1. Assertional concurrency control. In an assertional concurrency control, assertions, rather than data items, are locked. In particular, when Ti has completed the execution of Si,j, 1 5 j -C mi, and has not yet initiated the execution of si,j+t, it holds an assertional lock on Ai,j 3 where Ai.j is the postcondition of si,j in a maximally reduced proof. The lock prevents the execution of any step that interferes with Ai,j.’ A new transaction, T,, is made active when its precondition, Al,o, is true of the database state. When Tl is made active, it acquires an assertional lock on Al,o. That lock will certainly become available to Tl when the system quiesces, since Z will be true of the database state at that time and I =+ Al,o. Presumably, Al,0 will become true prior to that time.

To implement assertional locks, at design time it must be determined, for all i and j, which steps interfere with Ai,j, and at run time the assertional concurrency control must delay the execution of those steps while the lock on Ai,j is held. For example, in a simple implementation, the assertional concurrency control maintains an integer vector, Step, containing an element corresponding to each step of each transaction. If Step[kl corresponds to steps,,,, then the value of Step[k] is the number of currently locked assertions that s,,, interferes with, and s,,, is executable only when Step[k] = 0. The design time analysis yields, for a particular assertion, Ai.j, the set of steps that interfere with it. This set


can be represented as a (constant) binary vector, ZAi,i, such that ZAi,j[k] has value 1 ifs,,, interferes with A,,j and 0 otherwise. ZAi,j is added to (subtracted from) Step at run time when Ai,j is locked (unlocked). This algorithm can be optimized-the important point is that no interference checking need be done at run time. A similar approach can be used to determine when Al,0 is true. Note that the fact that Ai,j is locked does not mean that it is true of the database state. For example, a step, sU,“, that temporarily causes Ai,j to become false, might be in execution. In that case, the fact that s,,, does not interfere with Ai,j assures that Ai,j will again be true of the database state when s,,~ completes. If no steps are in execution, the conjunction of all locked assertions is true of the database state.

With an assertional concurrency control that allows only one step to be in execution at a time, the next step, si,j, of an active transaction, I;:, can be selected for execution if it does not interfere with the precondition of any step waiting to be executed. As a result, when si,j terminates, both Ai,j and the preconditions of waiting steps of all other active transactions are true of the new database state. If such an assertional concurrency control is implemented in a way that when execution of S~,J is initiated, Ti releases its lock on Ai,j-1 (i.e., Step := Step - ZAi,j-1) and acquires a lock on Ai,j (i.e., Step := Step + ZAi,j) then the condition for initiating a new step is that the step not interfere with any locked assertion (equivalently, its entry in Step is 0).

More generally, the steps of a number of different active transactions can be in execution concurrently. Hence, a lower-level concurrency control is needed to ensure that steps are effectively isolated. If that lower-level control implements a static algorithm, such as time stamp ordering, then the equivalent serial order of the steps in execution is known in advance to be the order of initiation. Generalizing from the simple situation discussed in the previous paragraph, the next step, si.j, of an active transaction can be selected for execution by the assertional concurrency control if si,j does not interfere with the the precondition of any step waiting to execute or the postcondition of any step in execution at the time si,j is selected (since it will be serialized after all steps that are in execution when it is initiated). If the assertional concurrency control is implemented in such a way that when execution of Si,j is initiated, Ti releases its lock on Ai,j-1 and acquires a lock on Ai,j then, as before, the condition for initiating a new step is that the step not interfere with any locked assertion (once again, its entry in Step is 0).

If the lower-level control is dynamic, such as two-phase locking, then the equivalent serial order of the executing steps is not known in advance. Hence a more conservative approach is appropriate. The next step, si,j, of an active transaction can be initiated by the assertional concurrency control if si,j does not interfere with either the pre- or postcondition of any step, s~,~, in execution at the time si,j is selected, and ifs,,” does not interfere with pOst(si,j) (s,,, must not interfere with pre(si,j) either, but that condition was checked when s,,, entered execution). If the assertional concurrency control is implemented in such a way that a step acquires a lock on its postcondition at the time it enters execution and releases the lock on its precondition when it completes execution, then the condition for initiating a new step, si,j, is that si,j not interfere with any locked assertion (once again, its entry in Step is 0) and no executing step interferes with post(si,j) (hence, it can be locked). Thus, for all active steps sU,“, ifs,,” is the kth step then ZAi,j[k] must be 0.

Deadlock takes on a somewhat different form in an assertional concurrency control: a situation can arise in which no step can be initiated since all waiting steps interfere with the precondition of some other waiting step. Standard deadlock detection and prevention algorithms can be used to deal with this problem. For example, a form of the banker’s


algorithm can be used for deadlock prevention. A step, Si.j, is a candidate for execution if both 3i.j and the sequence of steps Si,j+i; si,j+z; . . . ; Si,m, do not interfere with any locked assertion, where rni is the number of steps in transaction Ti .’ The second condition guarantees that the transaction can be run to completion in the state that results from the execution of si,j, and hence no deadlock can occur.

3.3. Weakening the dejinitions

Let Tl and Tz be two instances of T& (Fig. 3) executed concurrently on behalf of the same subscriber. The loop body of Tl interferes with the interstep assertions ZJ2 and I&, of T2. Hence, using the maximally reduced proof of T&, it appears that two buy transactions for the same subscriber cannot be interleaved.

We note, however, that Uz and ZiUb deal only with database consistency-the relationship between credit[sub] and cost[sub]-and since the updates to these variables performed by the two transactions commute, the database will be consistent when both Tl and T2 complete. Hence, it appears that it should be possible to interleave their execution.

To understand this apparent contradiction, we distinguish the two instances of the variable total-cost local to Tl and T2 using subscripts and define new assertions as follows

U21 = (cost[sub] + total-cost, + credit[sub] = C) A (credit[sub] > 0) (16) U22 = (cost[sub] + total-cost2 + cre.dit[sub] = C) A (credit[sub] > 0) (17)

U = (cost[sub] + total-cost1 + total-cost2 + credit[sub] = C) A (credit[sub] 2 0) (18)

Figure 4 contains a proof of Tl derived from the proof in Fig. 3 by replacing each assertion I& with I&, v 1722 and each assertion U2 with U21 v U. The proof in Fig. 4 is not a maximally reduced proof since it does not demonstrate that ZiUb is true on termination. It was constructed specifically to address the issue of interleaving of two particular transactions (for example, it makes assertions about a variable in Tz), whereas a maximally reduced proof considers a transaction in isolation.

The new proof is weaker than the original since, for example, it allows for the possibility that when T2 is executing concurrently with Tl and the loop body of Tl completes, either lJ21 is true (as in Fig. 3) or, if T2 has completed its first step but not yet completed its last step, U is true. A similar proof of T2 can be derived in a symmetric fashion and the two proofs do not interfere with each other. Since the proofs do not interfere, their interstep assertions accurately describe the database state when the two transactions are interleaved.

Taking the result of a buy transaction to be P3 A R3, Fig. 4 demonstrates that TI ‘s result is true when it terminates after having been interleaved with T2. Furthermore, when both Tl and Tz complete, the conjunction of their postconditions will be true, implying that ZiUb is true of the database (since [(Z&, v Uzl) A (ZiUb v U&] E Z&). Hence the interleaved execution of TI and T2 is correct. It is not valid, however, since the assertions in the maximally reduced proof of Fig. 3 are not true when the corresponding steps are executed. Thus validity is not a necessary condition for correctness.

This example demonstrates that although the invariant is not true when Tl terminates, it will be true after both Tl and Tz terminate. Similarly, it is possible to construct examples of transactions, T, and Tb, having the property that when their execution is interleaved, Tu’s result is not true when it terminates, but is true after both T, and Tb have terminated.


TL,(bidqrice, bidnum, sub) :: var totaZJhl, totalsostl, : integer := 0,O; begin

{Pz A (IL V Uz,) A (totallrhl = 0) A (totaIro& = 0)) while (totalAh < %dsum) do

Find cheapest offer in sellbook; let its-.$ndex be j; if ((credit[sub] < cost of ~eZLbook~j)

V (offer price of sellbookb] > bid-price)) then break; totallrhl := totaZJhl + 100; total-co+ := total-cost1 $ cost of seZZ..bookb]; credit[aub] := neditfsub] - cost of uellbookb];

cost[sab] := cost[rrub] + totaim&; {Ps A Rs A (I:, v U22))

end

Figure 4. A weakened proof of Ti”,,.

Such an execution might be acceptable in some applications but violates the definition of correctness presented earlier, which requires that the result of a transaction be true when it terminates.

3.4. Compensation

When transactions are decomposed into interleavable steps, the intermediate results of a transaction, Ti;:, are visible to other transactions. If Ti must be aborted, the before values it has seen cannot simply be restored. Instead, a compensating step, csi,j, must be executed for every step, Si,j, that has completed. cs,j need not return the database to the state it was in prior to the execution of si,j, nor is it necessary that it restore the database to a state that satisfies Ai,j-1 . It need only perform some action that the user accepts as satisfactorily reversing the effect of si,j. However, a compensating step must have the property that it can never be aborted [24]. Hence, we require that a compensating step never interferes with a locked assertion and hence be made to wait, since it might become involved in a deadlock.

Unless compensation is done with care, cascaded aborts might be required. Thus if Tj conditions its actions on an intermediate result of Ti, and that result is compensated for, it might be necessary to also abort Tj, an action referred to as cascaded abort.

We now prove a theorem that provides a condition on interleaving under which cascaded abort is never required. We assume that if si,j does not interfere with some interstep assertion, then the subsequent execution of cSi.j does not interfere with that assertion either. Thus if s;,j can be executed between sk,J and Sk.{+], then Si,j can be both executed and compensated for between sk,J and sk,J+l . Intuitively, S~,J+I does not require in its precondition any result computed by si,j (since the execution of Si,j need not precede that of sk,~+l); hence


the reversal of si,j should not affect our ability to execute sk,r+i. Under this assumption we can prove the following theorem:

?hEOREM. Let Si,j be the last uncompensated step of 7; in an (incomplete) schedule S. A compensating step, Csi,i, can be executed at any point in S after si,i without inducing cascaded abort iff it does not interfere with the postcondition of any step of a concurrent transaction that can be interleaved after si,j.

PROOF. Assume that the last uncompensated step of transaction z that has been executed in S is si, j. To demonstrate sufficiency we show that if the non-interference condition stated in the theorem is met, then csi,j does not interfere with any locked assertion (and thus can be executed at any point in S after si,j). Let Tk be an active transaction and let its last step in S be sk,[. Then post(sk,l) is locked. If sk,[ occurs before Si,j in S, then Si,j does not interfere with post&J) and by the assumption, csi,j does not interfere with that assertion either. If sk,J occurs after Si,j then it follows from the condition of the theorem that CSi,j does not interfere with post&) either. In both cases, CSi,j can be executed and Tk can subsequently continue execution despite changes to the database made by cSi,j.

Necessity follows from the requirement that csi,j never be made to wait. In a schedule in which sk,J is the last step, post&) is a locked assertion and hence CSi,j must not interfere with it. 0

The theorem states that if cSi,j does not interfere with the postcondition of a step, &J, that is interleaved after Si,j, then Tk can continue to function correctly after CSi,j is executed since the precondition of its next step, sk,J+i, remains true. The theorem gives a semantic basis for determining allowable interleavings and reasonable step decompositions when the need for compensation exists. Under the condition of the theorem, it follows that a compensating step never interferes with a locked assertion and hence is never required to wait.

To illustrate the relationship between compensation and transaction semantics, we once again modify the buy transaction. In a market with many stocks, it is desirable to allow multiple buy transactions, each operating on a different stock, to execute concurrently on behalf of the same subscriber, sub. If a two-phase lock protocol is used by the low-level concurrency control, significant delays might occur as a result of the repeated access by each such buy transaction to credit[sub]. To eliminate these delays, the buy transaction can be redesigned so that, as a separate initial step, the maximum credit the transaction might require is withdrawn from credit[sub] and placed in escrow before sellbook is searched. This makes it possible to remove the access to credit[sub] contained in the loop body of T’ buy. A final step must be added to restore to credit[sub] any unused credit that had been placed in escrow. The resulting transaction, Ti&,, is shown in Fig. 5. For simplicity we have eliminated cost and used the simpler invariant, I.

Note that, if bid-price is less than the offering price of any entry in the sell book, the transaction will make no purchases and the last step will return all the funds that were initially placed in escrow. Hence, the last step is a compensating step for the initial step. Since the last step of Tih, increments credit[sub], it interferes with any assertion that states that credit[sub] is less than some quantity. Rz (12) is an example of such an assertion. Hence if transactions attempting to buy distinct stocks for the same subscriber are to be allowed to execute concurrently and if the compensating approach of Tl&, is to be used, R2


T&,(bidgrice, bidsum, szLb) :: var totalAh, total-coat : integer := 0,O; CR: integer := 0; ( *initial value of subscriber’s credit, awciliary variable*) begin

{P2 A (credit[.wb] 2 0) A (totallrh = 0) A (total~ost = 0)) CR := wedit[sub]; if aedit[sub] 1 &id-price * b&Lnum then

t27edit[sub] := cred+b] - biid,price * bid-num; {P2 A (credit[sub] 2 0) A (CR 2 bid-price * &idAum)}

while (totalsh < bid-num) do Find cheapest offer in sellbooh; let its index be j; if (seZZ_book~].prke > &ii&-price)) then break endif; totalsh := totalsh + 100; total-cost := totalxost + cost of sellbooklj];

{Pz A (med;t[.wb] 2 0) A (CR 2 bid-price * &idnzLm)} end while;

(Pz A (c&it[sub] 2 0) A (CR 1 b&f-Fice * b&wm) A &)

medit[svb] :F credit[aub] + (bid-price * bidsum - total-cost); end if;

end {P3 A Rs A (c&it[sub] > 0))

Figure 5. A nonmodular decomposition of a buy transaction illustrating compensation.

must be weakened. The assertion we choose relates the total cost of the cheapest offer in sell-book to CR, the value of credit[sub] at the time the transaction is initiated, instead of to credit[sub]. The intermediate assertions used in the maximally reduced proof of Td:, are

Rq = (totalsh 2 bidnum) V(price of cheapest offer in sell-book exceeds bid-price) (19)

Rs E (CR < bid-price * bid_num) v (totalsh > bidnum) ~(price of cheapest offer in SELL-BOOK exceeds bid-price) (20)

If the assertions used in the annotated program of Fig. 5 are strong enough for the purposes of the application, then buy transactions can be arbitrarily interleaved, but sell transactions cannot be interleaved with buy transactions. If the application requires that the stronger invariant, I’, be maintained (for example, an audit transaction might require such an invariant), then buy transactions for the same subscriber can no longer be interleaved.

Recovery for a decomposed transaction is similar to recovery for an ordinary transaction. In addition to the records normally appended to the log, records to mark the beginning and end of each step are also appended. In contrast to a commit record, however, the record marking the end of a step need not be forced to stable storage when it is appended, since steps are not committed until the entire transaction commits. On recovery, any step in


progress at the time of the crash is rolled back in the normal way. Compensating steps are executed (in reverse order) for completed steps of uncomitted transactions.

4. Conclusion

In this paper we consider the problem of improving the performance of a transaction processing system by decomposing transactions into steps and replacing transaction isolation with step isolation. As a result, the duration of time that a transaction must hold a lock, and hence the duration of time that one transaction must wait for another, is reduced. Our analysis is based on the semantics of each transaction, derived from assertional proofs. We explore how transaction semantics can be used to define a new correctness criterion, to guide the decomposition, and to design an appropriate concurrency control, We also investigate the use of transaction semantics in determining interleavings that avoid the need for cascaded abort. Work is currently in progress to implement and evaluate a concurrency control based on these ideas.

The ideas in this paper are also applicable to distributed systems. The subtransactions of a global transaction correspond to steps. The isolation of each subtransaction is generally guaranteed by the local concurrency control of the site at which the subtransaction executes. This local control corresponds to the low-level control assumed here. In addition, a global concurrency control, corresponding to the assertional concurrency control, must be provided to guarantee that inter-subtransaction assertions are not interfered with. Work is currently in progress to design a distributed version of the assertional concurrency control for this purpose. Such a control directly addresses the problem of maintaining global database consistency constraints. While the assertional approach relaxes the requirements of serializability, it does not necessarily guarantee complete site autonomy (i.e., it does not guarantee that sites can arbitrarily commit or abort transactions based solely on the local situation). In those situations where the requirements of local autonomy conflict with the requirements of the assertional concurrency control, compensating subtransactions (which correspond to the compensating steps described above) can be invoked. Compensating subtransactions can be analyzed using the methods described in this paper.

Acknowledgments

Professor Bernstein was supported by the National Science Foundation under grant CCR9101524.

Notes

1. The assertional concurrency control described here does not use information about the state of the database at run time. A control that used such information could detect additional concurrency. For example, a step that decrements x by 1 interferes with the assertion x z 0. Hence, in the control presented here, if the assertion is locked the step will not be scheduled to run. However, if the control used run-time state information and if x were equal to 5, the control could determine that execution of the step would not cause the assertion to become false despite the interference. Such a control incurs the overhead of having to access the database in order to make scheduling decisions, and hence we do not consider it here.

2. This condition was suggested by Wai-Hong Leung.


References

1. D. Agrawal, A. El Abbadi, and A. Singh, “Consistency and orderability: Semantics based correctness criteria for databases,” ACM Transactions on Database Systems, vol. 18, no. 3, Sept. 1993.

2. B. Badinrath and K. Ramamritham, “Semantics-based concurrency control: Beyond commutativity,” ACM Transactions on Database Systems, March 1992.

3. F. Bancilhon, W. Kim, and H. Korth, “A model of cad transactions,” in Proc. of Eleventh Int’l Conf. on Very Large Databases, 1985.

4. N. Barghouti and G. Kaiser, “Concurrency control in advanced database applications,” ACM Computing Surveys, Sept. 1991.

5. A. Bernstein and P. Lewis, Concurrency in Programming and Database Systems, Jones and Bartlett, 1993.

6. A.J. Bernstein and PM. Lewis, “High performance transaction systems using transaction semantics,” Tech- nical Report 93/05, Dept. of Computer Science, State Univ. of New York at Stony Brook, July 1993.

7. A. Buchmann, M. Ozsu, M. Homick, D. Georgakopoulos, and F. Manola, “A transaction model for distributed object systems,” in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

” 8. P. Chrysanthis and K. Ramamritham, “Acta: The saga continues, in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

9. C. Davies, “Data processing spheres of control,” IBM Systems Journal, vol. 17, no. 2,1978. 10. C. Eastman, “Database facilities for engineering design,” Proceedings of the IEEE, vol. 69, no. 10, 1981. 11. A. Elmagarmid (Ed.), Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992. 12. A. Farrag and M. Ozsu, “Using semantic knowledge of transactions to increase concurrency,” ACM Transac-

tions on Database Systems, Dec. 1989. 13. H. Garcia-Molina, “Using semantic knowledge for transaction processing in a distributed database,” ACM

Transactions on Database Systems, June 1983. 14. H. Garcia-Molina and K. Salem, “Sagas,” in Proc. ACM SIGMOD Int’l. Conf. on Management of Data, 1987. 15. M. Herlihy, “Apologizing versus asking permission: Optimistic concurrency control for abstract data types,”

ACM Transactions on Database Systems, Mar. 1990. 16. C.A.R. Hoare, “An axiomatic basis for computer programming,” Communications of the ACM, Oct. 1969. 17. G. Kaiser, “A tlexible transaction model for software engineering,” in Proc. Sixth Int’l. Conf. on Data Engi-

neering, Feb. 1990. 18. H. Korth, W. Kim, and F. Bancilhon, “On long duration cad transactions,” Information Sciences, vol. 46,

1988. 19. H. Korth, E. Levy, and A. Silberschatz, “‘A formal approach to recovery by compensating transactions,” in

Proc. of 16th Int’l. Conf. on Very large Databases, 1990. 20. H. Korth and G. Speegle, “Formal model for correctness without serializability,” in Proc. of ACM SIGMOD

Conf. on Management of Data, June 1988. 21. P Krychniak, M. Rusinkiewicz, A. Sheth, and G. Thomas, “Bounding the effects of compensation under

relaxed multi-level serializability,” Technical Report UH-CS-92-06, Dept. of Computer Science, Univ. of Houston, 1992.

22. E. Kuhn, F. Puntigam, and A. Elmagarmid, “Multidatabase transaction and query processing in logic,” in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

23. E. Levy, H. Korth, and A. Silberschatz, “An optimistic commit protocol for distributed transaction management,” in Proc. of ACM SIGMOD Int’l. Conf. on Management of Data, May 1991.

24. E. Levy, H. Korth, and A. Silberschatz, “A theory of relaxed atomicity,” in Proc. of Tenth ACM Symp. on Principles of Distributed Computing, Aug. 1991.

25. N. Lynch, “Multilevel atomicity-a new correctness criterion for database concurrency control,” ACM Trans. on Database Systems, vol. 8, no. 4, Dec. 1983.

26. P. Muth, T. Rakow, W. Klas, and E. Neuhold, “A transaction model for an open publication environment,” in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

27. M. Nodine, S. Ramaswamy, and S. Zdonik, “A cooperative transaction model for design databases,” in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

28. S. Owicki and D. Gries, “An axiomatic proof technique for parallel programs I,” Acta Informatica, vol. 6, 1976.

29. R. Rastogi, S. Mehrotra, Y. Breitbart, H. Korth, and A. Silberschatz, “On correctness of non-serializable executions,” in Proc. of ACM Symp. on Principles of Database Systems, May 1993.


30. A. Reuter and H. Wachter, “The contract model,” Quarterly Bulletin of IEEE Computer Society Tech. Comm. on Data Engineering, March 199 1.

31. L. Sha, J. Lehoczky, and E. Jensen, “Modular concurrency control and failure recovery,” IEEE Trans. on Computers, vol. 37, no. 2, Feb. 1988.

32. D. Shasha, E. Simon, and P. Valduriez, “Simple rational guidance for chopping up transactions,” in Proc. of 11th ACM SIGMOD/PODS Conf., June 1992.

33. A. Sheth, M. Rusinkiewicz, and G. Karabatis, “Using polytransactions to manage inter-dependent data,” in Database Transaction Models for Advanced Applications, Morgan Kaufman, 1992.

34. D. Stemple, S. Mazumdar, and T. Sheard, “On the modes and meaning of feedback to transaction designers,” in Proc. ACM SIGMOD Int’l. Conf. on Management of Data, 1987.

3.5. A. Tuzhilin and P. Spirakis, “A semantic approach to correctness of concurrent transaction execution,” in Proc. of 4th ACM SIGACT-SIGMOD-SIGMOD-SIGART Symp. on Principles of Database Systems, 1985.

36. H. Wachter and A. Reuter, “The contract model,” Technical Report 8/91, Univ. of Stuttgart, 1991. 37. W. Weihl, “Commutativity-based concurrency control for abstract data types,” IEEE Trans. on Computers,

vol. 37, no. 12, Dec. 1988. 38. G. Weikum, “Principles and realization strategies of multilevel transaction management,” ACM Transactions

of Database Systems, vol. 16, no. 1, March 1991.

transaction decomposition using transaction semantics

Documents