Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 1 Transaction Models Chapter 4."— Presentation transcript:

1

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

3 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, The Idea of Atomic Actions n 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. n Except for simple instructions at the processor level, no operation is really atomic in the sense that it performs only one state transition. n 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. n In order for a higher-level operation to appear atomic, a number of precautions have to be taken: n The lower-level operations must not make any visible changes before it is clear that the top-level operation will succeed. n 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.

4 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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 statesor 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.

5 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

6 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

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

8 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Three Outcomes of a Flat Transaction

9 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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; }

10 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, A Sample Transaction Program - II longDoDebitCredit(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); }

11 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Limitations of Flat Transactions I 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. 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: What do we do with the open transaction?

12 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

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

14 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Limitations of Flat Transactions IV n Assume there are checking accounts. n Assume the transaction has done the interest processing of accounts. n Assume the system crashes at that point. n 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. n 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?

15 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

16 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

17 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Spheres of Control - Example I

18 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Spheres of Control - Example II

19 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Spheres of Control - Example III

20 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Spheres of Control - Example IV

21 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, A Notation for Transaction Models

22 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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 momentis that none of the results produced by B3 can finally be committed (even though they appear perfectly good from B3s 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 doneeither by itself or by invoking lower-level atomic actions must remain contained inside A2s sphere of control. In that sense, the commit of B3 depends on the commit of A2.

23 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

24 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

25 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, ABC Act-ID AC A Graphical Notation For Atomic Actions signal ports final states 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. The first one is the begin signal, which starts the atomic action; so the port is called B. begin The second one receives the commit signal; therefore, it is labeled C. commit The third one receives the abort signal; therefore, it is labeled A. abort After the begin signal has arrived, the atomic action is instantiated and gets a name that is eternally unique. The two boxes at the bottom represent the two possible final states. 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). Blocked signal ports and states that cannot be reached are shaded.

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

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

28 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Savepoints - The Basic Idea 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 Consider the trip planning example again: 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. S3:book flight from Milan to Pisa, same day S2: book flight from Frankfurt to Milan, same day

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

30 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Rules For Savepoints n Savepoints can be used to structure a transaction into a sequence of partial executions that can be rolled back individually. n Because none of the actions a transaction has executed become visible before the end of the transaction, they can be revoked at any time. n Since a transaction must be prepared to roll back completely, a partial rollback does not add anything new, technically. n 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. n When an external error occurs, the entire transaction gets rolled back - independent of any savepoints.

31 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, The Model For Savepoints System ABC TA1 AC Begin Work:1 B Save2 ABC AC Save3 ABC AC B Save Work:3 B Save Work:2 Save4 ABC AC B Save Work:4 A A A Rollback Work(2) 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.

32 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Solving the Ripa Problem 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(); If we assume the savepoint mechanism, a solution to the travel agents problem might look like this:

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

34 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Chained Transactions vs. Savepoints

35 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

36 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Nested Transactions I n A nested transaction is a tree of transactions, the sub-trees of which are either nested or flat transactions. n 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. n 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. n A sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits. n 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.

37 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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-transactions 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.

38 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Nested Transactions II

39 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Nested Transactions III

40 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Modularization and Nested Transactions

41 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Nested Transactions vs. Savepoints

42 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Distributed Transactions

43 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Multi-Level Transactions

44 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Using Multi-Level Transactions I

45 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Using Multi-Level Transactions II

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

47 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Long-Lived Transactions n 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 banks one million account records at the same time. n 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. n Such additional structuring may help to organize normal processing, but it does not contain the amount of work lost in case of a crash.

48 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 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.

49 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Using Processing Context

50 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, Finally: Let Us Consider the Banking Application Again n 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. n 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. n The problem with this approach is twofold: n 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. n 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). n It would be better to have some place in the database that always points to the point beyond which interest has to be computed.

51 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, The Banking Application - Basic Idea Accounts Acct-NoOwner Balance 1 Masha12, Vijay8, First, we have the Accounts relation:Second, we have a Restart relation: 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. PurposeLast_OK_Acct Interest0... Date

52 © Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, The Banking Application - Using Transactional Restart Here is the basic logic for updating 1,000,000 accounts in a restartable way: 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. { begin work; update Accounts set Balance = Balance * (1 + :interest_rate) where Acct_No between :LOA+1 and :LOA+1000; while (true) Start the processing loop. Update the next 1,000 accounts. update Restart set Last_OK_Acct = :LOA; LOA := LOA ; if LOA = then LOA = 0; Define the next restart point. When everything is complete, reset to 0. commit work; Next batch is done and restart point is set. if LOA = 0 then exit; }

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


Download ppt "© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999 1 Transaction Models Chapter 4."

Similar presentations


Ads by Google