Post on 26-Mar-2015
transcript
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
1
Aug. 2 Aug. 3 Aug. 4 Aug. 5 Aug. 6 9:00 Intro &
terminologyTP mons& ORBs
Logging &res. Mgr.
Files &Buffer Mgr.
Structuredfiles
11:00 Reliability Lockingtheory
Res. Mgr. &Trans. Mgr.
COM+ Access paths
13:30 Faulttolerance
Lockingtechniques
CICS & TP& Internet
CORBA/EJB + TP
Groupware
15:30 Transactionmodels
Queueing AdvancedTrans. Mgr.
Replication Performance& TPC
18:00 Reception Workflow Cyberbricks Party FREE
Transaction Models
Chapter 4
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
2
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
3
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
4
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
5
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
6
First Example of a Transaction
Begin Work opens a sphere of control
select ...read block read block read block
protectedaction
update ...read block write block
protectedaction
drill_hole ...real action
unprotectedactions
unprotectedactions
if (condition) Commit Workelse Rollback Work
insert ...write block
select ...read block
now do itdon’t do it at all
defer execution of real action
protectedaction
protectedaction
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
7
Three Outcomes of a Flat Transaction
Successful completion < 96% of all transactions
BEGIN WORK
Application requests termination (Suicide) > 3% of all transactions
BEGIN WORK
Rollback due to external cause like timeout etc.
Forced termination (Murder) > 1% of all transactions
BEGIN WORK
Operation 1
Operation 2
Operation k
COMMIT WORK
Operation 2
Operation 1
(I got lost ! )
ROLLBACK WORK
... ...
Operation 1
Operation 2
...
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
8
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
9
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
10
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?
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
11
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
12
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
13
Limitations of Flat Transactions IV
Assume there are 1.000.000 checking accounts. Assume the transaction has done the interest processing of
983.446 accounts. Assume the system crashes at that point. Thanks to atomicity (the A of ACID), all the updates that have
been done so far (983.446 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
14
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
15
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
16
Spheres of Control - Example I
A1
B1 B2C1
C2
A2
B3
B4
B5
Dynamically created for controlling the commitment of A1
S
D
D is a non-commitable data item
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
17
Spheres of Control - Example II
t
A
B
C
D
E
D1
D2
D3
D4
D5
D6
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
18
Spheres of Control - Example III
t
A
C
D
E
D1
D2
D3
D4
D5
D6
time
F
B
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
19
Spheres of Control - Example IV
t
A
C
D
E
D1
D2
D3
D4
D5
D6
time
F
B
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
20
A Notation for Transaction Models
active
committed aborted
ROLLBACK WORK
COMMIT WORKterminate
terminate
NULL
BEGIN WORK
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
21
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
22
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
23
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
24
A B C
Act-ID
A C
A Graphical Notation For Atomic Actions
signal ports
final states
An atomic action is represented bya square with some internal boxes.
On top, there are three signal portsthat can receive signal for the atomicaction.
The first one is the „begin“ signal, whichstarts the atomic action; so the port iscalled 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, theatomic 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, theatomic assumes the final committed state (C). If an abort signal arrived, the final state will be aborted (A).
Blocked signal ports and states that cannotbe reached are shaded.
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
25
Describing Flat Transactions - I
This action representsthe running system. It has been started and will nevercommit. But it may be aborted.
T1
A B C
A C
Here is the empty template fora new atomic action.
The creation of a new transactionintroduces an abort dependencyof this transaction from the systemaction.
When the commit signal arrives,the transaction goes into its finalcommitted state. No dependenciesremain.
B C
A B C
System
A C
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
26
Describing Flat Transactions - II
This action representsthe running system. It has been started and will nevercommit. But it may be aborted.
T1
A B C
A C
Let us assume anactive transaction again ...
When the abort signal arrives,the transaction enters the finalaborted state. No dependenciesremain.
A B C
System
A C
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
27
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 dayS2: book flight from Frankfurt to Milan, same day
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
28
Flat Transactions With Savepoints
Begin Work: 1action-aaction-b
Save Work: 2
action-faction-e
action-c
Save Work: 4
Save Work: 3action-d
action-g
Rollback Work(2)Rollback Work(2)
action-gSave Work: 4
action-faction-eaction-dSave Work: 3
action-c action-haction-i
Save Work: 5action-jSave Work: 6action-k
action-naction-m
action-lSave Work: 7
Rollback Work(7)Rollback Work(7)action-naction-m action-o
action-p
Save Work: 8action-q
Commit Work
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
29
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
30
The Model For Savepoints
System
A B C
TA1
A C
Begin Work:1
B
Save2
A B C
A C
Save3
A B C
A C
B
Save Work:3
B
Save Work:2
Save4
A B C
A C
B
Save Work:4
A
AA
Rollback Work(2)
All the steps between two Save Work commandsare encompassed by anatomic action. These atomicactions are threaded together by commit- and abort-dependencies.If one of them gets aborted,all subsequent atomic actionsare aborted, too.If one of them commits, itcauses all the previous onesto commit, too.
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
31
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 agent’s problem might look like this:
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
32
Chained Transactions
A B C
A C
A B C
A C
system C1
trigger
A B C
A CC2
trigger
a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one.
A B C
A C
A B C
A C
system C1
trigger
A B C
A CC2
trigger
A B C
A CC3
b) The first transaction in the chain has committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on "system".
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
33
Chained Transactions vs. Savepoints
A B C
A C
A B C
A C
system C1
trigger
A B C
A C
C2
trigger
A B C
A C
C1'
A B C
A C
restart
trigger
trigger
trigger
trigger
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
34
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
35
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
36
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
37
Nested Transactions II
BEGIN WORK . . . invoke sub-TA . . . . invoke sub-TA . . . . . invoke sub-TA . . . COMMIT WORK
BEGIN WORK invoke sub-TA invoke sub-TA . COMMIT WORK
BEGIN WORK . . .COMMIT WORK
BEGIN WORK . invoke sub-TA . COMMIT WORK
BEGIN WORK . ROLLBACK WORK
BEGIN WORK invoke sub-TA COMMIT WORK
BEGIN WORK . .COMMIT WORK
Top-level transaction Sub-transactions Sub-transactionsTk
Tk1
Tk2
Tk3
Tk11
Tk12
Tk31
BEGIN WORK . COMMIT WORK
Tk121
Sub-transactions
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
38
Nested Transactions III
A B C
A CT
trigger
A B C
A CT
trigger
A B C
A CT1
trigger
A B C
A CT
trigger
A B C
A CT2T1
A B C
A C
a) Root transaction T is running
b) Sub-transaction T1 has been started
triggerwait
system system system
T11A B C
A C
trigger
wait
wait
wait
c) T1 has created sub-transaction T11, and after that the root transaction starts another sub-transaction T2
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
39
Modularization and Nested Transactions
module acode func_b . func_c func_d . return
module bcode func_e func_f return
module gcode func_h return
module dcode func_g return
module hcode return
module fcode return
module ccode return
module ecode return
Assuming sequential excution in all modules and transaction protection per module, we get the following nested transaction (let Tx be the transaction protecting the execution of function_x):
BOT(Ta)
BOT(Tb)
BOT(Te)EOT(Te)BOT(Tf)EOT(Tf)
EOT(Tb)BOT(Tc)EOT(Tc)BOT(Td)
BOT(Tg)
BOT(Th)EOT(Th)
EOT(Tg)
EOT(Td)
EOT(Ta)Top
L2
L1
L0
time
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
40
Nested Transactions vs. Savepoints
Tk
Tk1
TK2
Tk3
Tk11
Tk12
Tk121
Tk31
time
establish savepoint
s11
s121
s2
s31
s3
s1
s12
commit
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
41
Distributed Transactions
A B C
A C
T
trigger
A B C
A C
T
trigger
A B C
A C
T1
trigger
a) Root transaction T is running
b) Remote sub-transaction T1 has been started
system system
trigger
trigger trigger
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
42
Multi-Level Transactions
A B C
A C
A B C
A C
system
T
trigger
A B C
A C
A B C
A C
system
T
trigger
A B C
A CN
trigger
A B C
A C
A B C
A C
system
T
trigger
A B C
A CCNN
A B C
A C
a) Top-level transaction T is running
b) Sub-transaction N has been started
c) Sub-transaction N has committed and has installed its compensation transaction CN that will get started if T aborts. CN must commit.
trigger
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
43
Using Multi-Level Transactions I
T
SELECT ... INSERT ... UPDATE ... SELECT ...
Insert tuple Insert B-tree entry
Insert address table entry
Update page Locate position Insert entry
Split page
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
44
Using Multi-Level Transactions II
Original sequence of actions
Sequence of counter-actions
Find free page; let the number be P Update free space information
Locate free space information for page P Update free space information
Read page P Update the page header Insert tuple t
Read page P Remove tuple t Update page header
Grab free database key K
Release database key K
Insert K into page header of page P into entry pertaining to t
Remove K from t's page header entry in page P
Read page containing entry for database key value K Insert pointer to P into table entry
Read page containing entry for database key value K Remove pointer from table entry Remember page number P
Invocation : Insert_Tuple (t,ret_code)
Invocation : Remove_Tuple(K,ret_code)
t t
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
45
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
46
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
47
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
48
Using Processing Context
SimpleProgram() { read (input_message); BEGIN WORK; /* perform computation on input message and context */; send (output_message); COMMIT WORK; };
Private context
Global context
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
49
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
50
The Banking Application - Basic Idea
Accounts
Acct-No Owner Balance
1 Masha 12,345.80
2 Vijay 8,433.17
... ... ...
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 computationstouching all tuples must be resumed incase the computation gets interrupted bya crash. Normally, the “last OK account”is 0, which means no long runningcomputation is active. Otherwise, it contains the highest account number processed by the last successful transaction.
Purpose Last_OK_Acct
Interest 0
......
Date
19981031
...
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
51
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 :LOAfrom Restart where Purpose = “interest”;
Note that this will yield 0 if everything is OK and we start computing theinterest at the end of the month.
{ begin work;
update Accountsset 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 Restartset Last_OK_Acct = :LOA;
LOA := LOA + 1000;if LOA = 1000000 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;}
© Jim Gray, Andreas Reuter Transaction Processing - Concepts and Techniques WICS August 2 - 6, 1999
52
Sagas
A B C
A
A B C
A C
system S1
trigger
A B C
A C
S2
A B C
A C
CS2
A B C
A C
C
CS1
A B C
A C
S3
C
trigger
trigger