Transaction Models Chapter 4

Transaction Models Chapter 4
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

The Idea of Atomic Actions
An atomic action is an operation that at some level of abstraction appears to be atomic in the following sense: Either the action is executed completely (and successfully), or it has not happened at all. In particular, if it is not successful, it has not left any side effects. Except for simple instructions at the processor level, no operation is really atomic in the sense that it performs only one state transition. Most operations are implemented by a sequence of more primitive operations (i.e. programs), which in turn are implemented by sequences of even more primitive operations, etc. In order for a higher-level operation to appear atomic, a number of precautions have to be taken: The lower-level operations must not make any “visible” changes before it is clear that the top-level operation will succeed. For any temporary changes the lower-level operations make, it must be made sure that they do not become visible, and that they can be revoked automatically should anything go wrong. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

The ACID Properties of Flat Transactions - I
Atomicity: A state transition is said to be atomic if it appears to jump from the initial state to the result state without any observable intermediate states—or if it appears as though it had never left the initial state. It holds whether the transaction, the entire application, the operating system, or other components function normally, function abnormally, or crash. For a transaction to be atomic, it must behave atomically to any outside ‘‘observer”. Consistency: A transaction produces consistent results only; otherwise it aborts. A result is consistent if the new state of the database fulfills all the consistency constraints of the application; that is, if the program has functioned according to specification. Isolation: Isolation means that a program running under transaction protection must behave exactly as it would in single-user mode. That does not mean transactions cannot share data objects. The definition of isolation is based on observable behavior from the outside, rather than on what is going on inside. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

The ACID Properties of Flat Transactions - II
Durability: Durability requires that results of transactions having completed successfully must not be forgotten by the system; from its perspective, they have become a part of reality. Put the other way around, this means that once the system has acknowledged the execution of a transaction, it must be able to reestablish its results after any type of subsequent failure, whether caused by the user, the environment, or the hardware components. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

A Classification of Action Types
Unprotected actions: These actions lack all of the ACID properties except for consistency. Unprotected actions are not atomic, and their effects cannot be depended upon. Almost anything can fail. Protected actions: These are actions that do not externalize their results before they are completely done. Their updates are commitment controlled, they can roll back if anything goes wrong, and once they have reached their normal end, there will be no unilateral rollback. Protected actions have the ACID properties. Real actions: They affect the real, physical world in a way that is hard or impossible to reverse. Drilling a hole is one example; firing a missile is another. Real actions can be consistent and isolated; once executed, they are definitely durable. But in the majority of cases, they are irreversible, which means it is much more difficult to make them appear atomic, because the option of going back in case the proper result cannot be achieved does not exist. In some cases, pretending atomicity for a real action is not possible at all. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

First Example of a Transaction
Begin Work opens a sphere of control select ... read block read block read block protected action unprotected actions update ... read block write block protected action unprotected actions drill_hole ... real action defer execution of real action insert ... write block protected action select ... read block protected action now do it if (condition) Commit Work else Rollback Work don’t do it at all © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Three Outcomes of a Flat Transaction

A Sample Transaction Program - I
exec sql begin declare section; long Aid, Bid, Tid, delta, Abalance; exec sql end declare section; DCApplication() {read input msg; exec sql begin work; Abalance = DoDebitCredit(Bid, Tid, Aid, delta); send output msg; exec sql commit work; } © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

A Sample Transaction Program - II
long DoDebitCredit(long Bid, long Tid, long Aid, long delta) { exec sql update accounts set Abalance = Abalance + :delta where Aid = :Aid; exec sql select Abalance into :Abalance from accounts where Aid = :Aid; exec sql update tellers set Tbalance = Tbalance + :delta where Tid = :Tid; exec sql update branches set Bbalance = Bbalance + :delta where Bid = :Bid; exec sql insert into history(Tid, Bid, Aid, delta, time) values (:Tid, :Bid, :Aid, :delta, CURRENT); return(Abalance); } © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Limitations of Flat Transactions I
Here is a simple travel application. Let us assume we want to go from San Francisco, CA, to Ripa in Italy. The reservation procedure could start like this: BEGIN WORK S1: book flight from San Francisco to Frankfurt S2: book flight from Frankfurt to Milan, same day S3: book flight from Milan to Pisa, same day Problem: There is no way to get to Ripa from Pisa the same day, except in a rental car. But you do not want to drive at night. What do we do with the open transaction? © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Limitations of Flat Transactions II
What can the travel agent do in that situation? One solution might be to have you go from Milan to Florence rather than Pisa, and then go by train from there. Or the situation might require your going from Frankfurt to Genoa, or perhaps somewhere else. The point is, given a flat transaction model, the travel agent has only two choices: Issue ROLLBACK. This gives up much more of the previous work than is necessary; in particular, there is no need to give back the reservation on the flight to Frankfurt. Explicitly cancel all the reservations that are no longer useful. This is tedious at best. Furthermore, explicit cancellation might not be so easy, because some of the very cheap special fares come with a high cancellation fee. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Limitations of Flat Transactions III
ComputeInterest() { real interest_rate; /* */ receive (interest_rate); /* monthly interest rate */ /* */ exec sql begin work; /* start the transaction */ exec sql UPDATE checking_accounts /* */ SET account_balance = /* compute accumulated*/ account_balance*(1+interest_rate); /* interest */ /* modify all accounts */ send (“done”); /* notify client */ exec sql commit work; /* declare victory */ return; /* */ }; © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Limitations of Flat Transactions IV
Assume there are checking accounts. Assume the transaction has done the interest processing of accounts. Assume the system crashes at that point. Thanks to atomicity (the A of ACID), all the updates that have been done so far ( of them) will be rolled back - even though none of those updates was incorrect in any way. After the rollback, the database will be in the state before the transaction started. So if you are the database administrator, you have lost hours worth of work - and probably have made some customers very angry. What else could you do? © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Spheres of Control - The Idea
Bjork and Davies in the early 70s established the notion of spheres of control (SOC); the following definitions are largely quoted from their seminal paper: Process control: Process control ensures that the information required by an atomic process is not modified by others, and it constrains the dependencies that another process may place on the updates made by this process. Process atomicity: Process atomicity is the amount of processing one wishes to consider as having identity. It is the control over processing that permits an operator to be atomic at one level of control, while the implementation of that operator may consist of many parallel and/or serial atomic operators at the next lower level of control. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Spheres of Control - The Idea
Process commitment: While a function is in process, changes of state are being made only by that function or they are expressly known to that function. This allows the establishment of a single point to which one can return for rerun purposes independently of the error detected or the number of functions since that point. Preventing process commitment by holding (controlling) the use of its results permits the system to perform a unilateral backout (process undo) over much larger units of process. Unilateral here means without having to request permission from each participant in a process. In summary, process commitment control is the containment of the effects of a process, even beyond the end of the process. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Spheres of Control - Example I

Spheres of Control - Example II

Spheres of Control - Example III

Spheres of Control - Example IV

A Notation for Transaction Models

Dependencies Between Transactions
Structural dependencies: These reflect the hierarchical organization of the system into abstract data types of increasing complexity. The atomic action surrounded by SOC B4 is structurally dependent on A2, because the implementation of A2 uses B3 (as well as B4 and 5). The consequence of this - forgetting about sphere S for the moment—is that none of the results produced by B3 can finally be committed (even though they appear perfectly good from B3’s perspective) until A2 decides to commit. The reason is simple: A2 appears as an atomic action to the outside. So, as long as it has not decided which way to go (all or nothing), everything it has done—either by itself or by invoking lower-level atomic actions—must remain contained inside A2’s sphere of control. In that sense, the commit of B3 depends on the commit of A2. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Dependencies Between Transactions
Dynamic dependencies: As explained previously, this type of dependency arises from the use of shared data. Let us briefly recapitulate the idea illustrated in Example 1. Up to a certain point, A1 and A2 are disjoint atomic actions. Some action within A1 has produced data object D, but A1 is still active. If someone inside A2 uses D, then it is quite obvious that any results based on that become wrong at the moment A1 decides to roll back, because that makes D return to its previous value. As a consequence, A2 has become dependent upon A1 in the sense that A2 can commit only if A1 does. Structural dependencies reflect the invocation hierarchy of the system, whereas dynamic dependencies can envelop any number of otherwise unrelated atomic actions. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Describing Transaction Models by Rules
Active part: As can be seen from the state-transition diagram, there are three events causing an atomic action to change its state: the BEGIN WORK, the ROLLBACK WORK, and the COMMIT WORK. Transaction models can define conditions that trigger these events. Consider the example in the SoC scenario again: the event ROLLBACK WORK for atomic action B3 can be triggered by the program running inside B3 (this is true for all atomic actions); but, because of the structural dependency, there is an additional condition saying that the abort of A2 triggers the rollback of B3. Passive part: Atomic actions that depend on other transactions might not be able to make certain state transitions all by themselves. For example, the signal COMMIT WORK for B3 is not sufficient to actually commit B3; that can only happen if A2 is ready to commit, too, since A2 is the higher-level sphere of control. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

A Graphical Notation For Atomic Actions
abort begin commit An atomic action is represented by a square with some internal boxes. On top, there are three signal ports that can receive signal for the atomic action. A B C signal ports The first one is the „begin“ signal, which starts the atomic action; so the port is called B. Act-ID final states A C The second one receives the commit signal; therefore, it is labeled C. The two boxes at the bottom represent the two possible final states. The third one receives the abort signal; therefore, it is labeled A. After arrival of the commit signal, the atomic assumes the final committed state (C). If an abort signal arrived, the final state will be aborted (A). After the begin signal has arrived, the atomic action is instantiated and gets a name that is eternally unique. Blocked signal ports and states that cannot be reached are shaded. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Describing Flat Transactions - I
System This action represents the running system. It has been started and will never commit. But it may be aborted. When the commit signal arrives, the transaction goes into its final committed state. No dependencies remain. A B C B C The creation of a new transaction introduces an abort dependency of this transaction from the system action. Here is the empty template for a new atomic action. T1 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Describing Flat Transactions - II
Let us assume an active transaction again ... A B C System This action represents the running system. It has been started and will never commit. But it may be aborted. A B C When the abort signal arrives, the transaction enters the final aborted state. No dependencies remain. T1 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Savepoints - The Basic Idea
Consider the trip planning example again: BEGIN WORK S1: book flight from San Francisco to Frankfurt S2: book flight from Frankfurt to Milan, same day S3: book flight from Milan to Pisa, same day S2: book flight from Frankfurt to Milan, same day S3: book flight from Milan to Pisa, same day Problem! In that case it would help if we could do a partial rollback rather than aborting the entire transaction. So if we could say: Rollback to the state S2, we would be back to Milan, so to speak. A rollback to the state S1 would get us back to Frankfurt, while still being in the same transaction. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Flat Transactions With Savepoints
Begin Work: 1 action-a action-b Save Work: 2 action-c action-c action-h action-i Save Work: 3 Save Work: 3 action-d action-d Save Work: 5 action-e action-e action-j action-f action-f Save Work: 6 action-k Save Work: 4 Save Work: 4 action-l action-g action-g Save Work: 7 Rollback Work(2) Rollback Work(2) action-o action-m action-m action-p action-n action-n Rollback Work(7) Rollback Work(7) Save Work: 8 action-q Commit Work © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Rules For Savepoints Savepoints can be used to structure a transaction into a sequence of partial executions that can be rolled back individually. Because none of the actions a transaction has executed become “visible” before the end of the transaction, they can be revoked at any time. Since a transaction must be prepared to roll back completely, a partial rollback does not add anything new, technically. When a transaction rolls back to an internal savepoint, the actions that are undone appear like they had never happened - even to the transaction itself. When an external error occurs, the entire transaction gets rolled back - independent of any savepoints. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

The Model For Savepoints
System Begin Work:1 B B Save Work:3 A Rollback Work(2) A B C TA1 Save3 A B C A All the steps between two Save Work commands are encompassed by an atomic action. These atomic actions are threaded together by commit- and abort- dependencies. If one of them gets aborted, all subsequent atomic actions are aborted, too. If one of them commits, it causes all the previous ones to commit, too. B Save Work:2 B Save Work:4 Save2 A B C Save4 A B C A © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Solving the Ripa Problem
If we assume the savepoint mechanism, a solution to the travel agent’s problem might look like this: Begin_Work(); book flight from San Francisco to Frankfurt step1 := Save_Work(some_data); book flight from Frankfurt to Milan, same day step2 := Save_Work(some_data); book flight from Milan to Pisa, same day step3 := Save_Work(some_data); if (problem) then { some_data := Rollback_Work(step1); book flight from Frankfurt to Genoa; step4 := Save_Work(some_data); book train from Genoa to Viareggio; } Commit_Work(); © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Chained Transactions © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Chained Transactions vs. Savepoints

Chained Transactions vs. Savepoints
Workflow structure: Chained transactions allow a substructure to be imposed on a long-running application program, just as savepoints do. Commit versus savepoint: Since the chaining step irrevocably completes a transaction, rollback is limited to the currently active transaction. Lock handling: COMMIT allows the application to free locks that it does not later need. Work lost: Savepoints allow for a more flexible state restoration than do flat transactions only as long as the system functions normally. Restart handling: The chained transaction scheme, on the other hand, reestablishes the state of the most recent commit; that is, less work is lost in that situation. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Nested Transactions I A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. Transactions at the leaf level are flat transactions. The distance from the root to the leaves can be different for different parts of the tree. The transaction at the root of the tree is called top-level transaction, the others are called sub-transactions. A transaction's predecessor in the tree is called parent; a sub-transaction at the next lower level is also called a child. A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back. This combined with the previous point is the reason why sub-transactions have only ACI, but not D. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Nested Transactions I Commit rule: The commit of a sub-transaction makes its results accessible to the parent transaction only. The sub-transaction will finally commit (i.e. release its results to the outside world) if and only if it has committed itself locally and all its ancestors up to the root have finally committed. Rollback rule: If a (sub-) transaction at any level of nesting is rolled back, all its sub-transactions are also rolled back, independent of their local commit status. This is applied recursively down the nesting hierarchy. Visibility rule: All changes done by a sub-transaction become visible to the parent transaction upon the sub-transaction’s commit. All objects held by a parent transaction can be made accessible to its sub-transactions. Changes made by a sub-transaction are not visible to its siblings. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Nested Transactions II

Nested Transactions III

Modularization and Nested Transactions

Nested Transactions vs. Savepoints

Distributed Transactions

Multi-Level Transactions

Using Multi-Level Transactions I

Using Multi-Level Transactions II

Using Multi-Level Transactions III
Multi-level transactions can be used if the following structural requirements are fulfilled: Abstraction hierarchy: The entire system consists of a strict hierarchy of objects with their associated operations. Layered abstraction: The objects of layer n are completely implemented by using operations of layer n-1. Discipline: There are no shortcuts that allow layer n to access objects on a layer other than n-1. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Long-Lived Transactions
With all the transaction models introduced so far there is one problem that has been mentioned before, namely how to proceed when the unit of consistent state transition requires updating all of the bank’s one million account records at the same time. By making the whole update operation a flat transaction, the “exactly once” semantics are obtained, but at an unacceptably high price in the case of a restart will be charged by the system. Neither making a nested transaction nor taking savepoints will help, because in either case the acid property is still maintained for the entire transaction. Such additional structuring may help to organize normal processing, but it does not contain the amount of work lost in case of a crash. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Transaction Processing Context
Transaction: Cursor c introduced earlier falls into this category. Since sql cursors cannot be passed across transaction boundaries, a cursor position is a typical example of transaction context. Program: If a program executes a series of transactions, then program context contains the information about which transaction was committed last. Terminal: Terminal context may contain a list of users who are allowed to use this terminal, a list of functions that can be invoked from that terminal, the last window that was displayed on that terminal, and so on. User: User context may contain the next password the user must produce in order to be admitted, or the last order number the user has worked on, and so forth. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Using Processing Context

Finally: Let Us Consider the Banking Application Again
When you organize the update of the 1,000,000 accounts into, say, 1,000 transactions, each of which does 1,000 updates, then the problem is that after a crash you do not know which accounts you already touched. One “solution” would be to add an attribute to the Accounts - relation that contains the date of the recent interest computation. After a crash one could find the account with the lowest account number that has a date older than the current day in this attribute. That is the point from which to resume the interest computation. The problem with this approach is twofold: First, you introduce an attribute into the Accounts relation which otherwise you would not keep at all. So it has nothing to do with the application, but with problems of system administration. Second, finding the point for resuming the computation after a crash is fairly expensive (finding the minimum of some attribute value requires the system to touch all tuples). It would be better to have some place in the database that always points to the point beyond which interest has to be computed. © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

The Banking Application - Basic Idea
First, we have the Accounts relation: Second, we have a Restart relation: Acct-No Owner Balance 1 Masha 12,345.80 2 Vijay 8,433.17 ... Purpose Last_OK_Acct Interest ... Date Restart A tuple in the restart relation specifies, at which point long-running computations touching all tuples must be resumed in case the computation gets interrupted by a crash. Normally, the “last OK account” is 0, which means no long running computation is active. Otherwise, it contains the highest account number processed by the last successful transaction. Accounts © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

The Banking Application - Using Transactional Restart
Here is the basic logic for updating 1,000,000 accounts in a restartable way: while (true) Start the processing loop. { begin work; select Last_OK_Acct into :LOA from Restart where Purpose = “interest”; Note that this will yield 0 if everything is OK and we start computing the interest at the end of the month. update Accounts set Balance = Balance * (1 + :interest_rate) where Acct_No between :LOA+1 and :LOA+1000; Update the next 1,000 accounts. LOA := LOA ; if LOA = then LOA = 0; Define the next restart point. When everything is complete, reset to 0. update Restart set Last_OK_Acct = :LOA; Next batch is done and restart point is set. commit work; if LOA = 0 then exit; } © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999

Sagas © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 WICS 1999 Transaction Processing: Gray & Reuter

Transaction Models Chapter 4

Similar presentations

Presentation on theme: "Transaction Models Chapter 4"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Transaction Models Chapter 4

Similar presentations

Presentation on theme: "Transaction Models Chapter 4"— Presentation transcript:

Similar presentations

About project

Feedback