Transaction Models
9:00
11:00
Aug. 2
Intro &
terminology
Reliability
13:30
15:30
18:00
Fault
tolerance
Transaction
models
Reception
Aug. 3
Aug. 4
Aug. 5
Aug. 6
TP mons
Logging &
Files &
Structured
& ORBs
res. Mgr.
Buffer Mgr.
files
Locking Res. Mgr. &
COM+
Access paths
theory
Trans. Mgr.
Locking
CICS & TP
CORBA/
Groupware
techniques & Internet
EJB + TP
Queueing
Advanced
Replication Performance
Trans. Mgr.
& TPC
Workflow Cyberbricks
Party
FREE

Chapter 4
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
1
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
2
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
3
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
4
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
5
First Example of a Transaction
Begin Work
protected
action
select ...
protected
action
update ...
real action
drill_hole ...
protected
action
insert ...
protected
action
select ...
opens a sphere of control
read block read block read block unprotected
actions
read block write block
write block
unprotected
actions
defer execution
of real action
read block
if (condition) Commit Work
else
Rollback Work
© Jim Gray, Andreas Reuter

Transaction Processing - Concepts and Techniques
now do it
don’t do it at all
WICS August 2 - 6, 1999
6
Three Outcomes of a Flat
Transaction
BEGIN WORK
BEGIN WORK
BEGIN WORK
Operation 1
Operation 1
Operation 1
Operation 2
...
Operation 2
...
Operation 2
...
Operation k
(I got lost ! )
COMMIT WORK
Successful completion
< 96% of all transactions
© Jim Gray, Andreas Reuter
ROLLBACK WORK
Application requests
termination (Suicide)
> 3% of all transactions
Transaction Processing - Concepts and Techniques

Rollback due to external
cause like timeout etc.
Forced termination
(Murder)
> 1% of all transactions
WICS August 2 - 6, 1999
7
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
8
A Sample Transaction Program - II
long
{
© Jim Gray, Andreas Reuter
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); }
Transaction Processing - Concepts and Techniques

WICS August 2 - 6, 1999
9
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
10
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
11
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
12
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
13
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
14
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

15
Spheres of Control - Example I
S
A2
B3
A1
B1
B2
C1

B4
C2
B5
D
D is a non-commitable data item
Dynamically created for controlling the commitment of A1
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
16
Spheres of Control - Example II
D4
D
D2
A
E
D3
B
D1
C
© Jim Gray, Andreas Reuter

D6
D5
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
t
17
Spheres of Control - Example III
F
D4
D
D2
A
D6
E
D3
B
D1
C
© Jim Gray, Andreas Reuter

D5
Transaction Processing - Concepts and Techniques
time
t
WICS August 2 - 6, 1999
18
Spheres of Control - Example IV
F
D4
D
D2
A
E
D3
B
D1
C
© Jim Gray, Andreas Reuter

D6
D5
Transaction Processing - Concepts and Techniques
time
WICS August 2 - 6, 1999
t
19
A Notation for Transaction Models
BEGIN WORK
active
NULL

COMMIT
terminate
WORK
ROLLBACK
WORK
terminate
committed
© Jim Gray, Andreas Reuter
aborted
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
20
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
21
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
22
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
23
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.
The first one is the „begin“ signal, which
starts the atomic action; so the port is
called B.
A
B C
signal ports

Act-ID
A
C
final states
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 the begin signal has arrived, the
atomic action is instantiated and gets a
name that is eternally unique.
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.
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
24
Describing Flat Transactions - I
A
B
C
System
A
A
C
B
C
T1
A
© Jim Gray, Andreas Reuter
C
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
of a new
transaction
Herecreation
is the empty
template
for
the
transaction
goes
into
its
final
introduces
an action.
abort dependency
a new atomic
committed
state. No
dependencies
of
this transaction
from
the system
remain.
action.
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
25
Describing Flat Transactions - II
Let us assume an
active transaction
again ...
A
B
C
System
A
A
C
B
C
T1
A
© Jim Gray, Andreas Reuter
C
This action represents
the running system. It has
been started and will never
commit. But it may be aborted.

When the abort signal arrives,
the transaction enters the final
aborted state. No dependencies
remain.
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
26
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

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.Transaction Processing - Concepts and Techniques
© Jim Gray, Andreas Reuter
WICS August 2 - 6, 1999
27
Flat Transactions With Savepoints
Begin Work: 1
action-a
action-b
Save Work: 2
action-c
Save Work: 3
action-d
action-e
action-f
Save Work: 4
action-g
Rollback Work(2)
© Jim Gray, Andreas Reuter
action-h
action-i
Save Work: 5
action-j
Save Work: 6
action-k
action-l
Save Work: 7
action-m
action-n
Rollback Work(7)
Transaction Processing - Concepts and Techniques

action-o
action-p
Save Work: 8
action-q
Commit Work
WICS August 2 - 6, 1999
28
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
29
The Model For Savepoints
System
Begin Work:1
A
B
C
TA1
A
C
Save Work:2
A
B
C
Save2
A
© Jim Gray, Andreas Reuter
C
Save Work:3
A
B
C
All the steps between two
Save Work commands

Save3
are encompassed by an
atomic action. These atomic
A
C
Rollback
actions are
threadedWork(2)
together
by commit- and abortSave Work:4 dependencies.
If one of them gets aborted,
all subsequent atomic actions
A B C
are aborted, too.
Save4
If one of them commits, it
causes all the previous ones
A
C
to commit, too.
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
30
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
31
Chained Transactions
A
B C
system
A
C
A
B C
C1
A
C
trigger
A
B C
C2
A
C
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
system
A
C
trigger
A
B
C
A
C1
A
B
C
A
C2
C
A
B
C
C3
C
A
C
trigger
b) The first transaction in the chain has committed; the
second one got started as part of commit of C1. Now
structurally
on "system".
© Jim Gray, Andreas Reuter the second one is
Transaction
Processing dependent
- Concepts and Techniques
WICS August 2 - 6, 1999
32
Chained Transactions vs. Savepoints
trigger
A
B
C
restart
A
C
A
B
C

C1'
A
C
trigger
trigger
A
B
C
system
A
trigger
© Jim Gray, Andreas Reuter
C
trigger
A
B
C
A
C1
A
B
C
C2
C
A
C
trigger
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
33
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
34
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 subtransaction 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
35
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
36
Nested Transactions II
Top-level transaction
Tk
BEGIN WORK
.
.
.
invoke sub-TA
.
.
.
.
invoke sub-TA
.
.
.
.
.
invoke sub-TA
.
.
.
COMMIT WORK
© Jim Gray, Andreas Reuter
Sub-transactions
Tk1
BEGIN WORK
invoke sub-TA
invoke sub-TA
.
COMMIT WORK
Tk2
Sub-transactions
Sub-transactions
Tk11
BEGIN WORK
.
ROLLBACK WORK
Tk12
Tk121

BEGIN WORK
invoke sub-TA
BEGIN WORK
.
COMMIT WORK COMMIT WORK
BEGIN WORK
.
.
.COMMIT WORK
Tk3
BEGIN WORK
.
invoke sub-TA
.
COMMIT WORK
Tk31
BEGIN WORK
.
.COMMIT WORK
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
37
Nested Transactions III
system
system
system
trigger
trigger
trigger
A B C
T
A C
A B C
T
A C
A B C
triggerwait
a) Root transaction
T is running
A B C
T1
A C
T
A
C
trigger
trigger
A B C
T1
A C
wait

A B C
T2
A C
wait
b) Sub-transaction T1
has been started
© Jim Gray, Andreas Reuter
A B C
T11
A C
wait
c) T1 has created sub-transaction T11, and
after that the root transaction starts
anotherand
sub-transaction
T2WICS August 2 - 6, 1999
Transaction Processing - Concepts
Techniques
38
Modularization and Nested
Transactions
module a
code
func_b
.
func_c
func_d
.
return
module d
code
func_g
return
module b
code
func_e
func_f
return
module e
code
return
module f
code
return
module c
code
return
module g
code
func_h
return

module h
code
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):
Top BOT(Ta)
L2 BOT(Tb)
L1
EOT(Ta)
EOT(Tb)BOT(Tc)EOT(Tc)BOT(Td)
BOT(Te)EOT(Te)BOT(Tf)EOT(Tf)
L0
© Jim Gray, Andreas Reuter
BOT(Tg)
EOT(Td)
EOT(Tg)
BOT(Th)EOT(Th)
time
Transaction Processing
- Concepts and Techniques
WICS August 2 - 6, 1999
39
Nested Transactions vs. Savepoints
establish
savepoint
Tk
Tk11
Tk1
s1
s11
s12
Tk121
Tk12

s121
s2
TK2
Tk31
s3
s31
Tk3
commit
time
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
40
Distributed Transactions
system
system
trigger
A
trigger
B
C
trigger
A
B
T
A
trigger
C
T
C
A
C
trigger
A

trigger
B
C
T1
A
a) Root transaction
T is running
© Jim Gray, Andreas Reuter
C
b) Remote sub-transaction T1
has been started
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
41
Multi-Level Transactions
A B C
system
A
C
A B C
system
A
C
A B C
system
A
C
trigger
trigger
trigger
A B C
T
A C
A B C
A B C
T
A C
a) Top-level transaction
T is running
T
A
C
trigger
trigger
A B C
N
A C

A B C
N
A C
A B C
CN
A C
b) Sub-transaction N
has been started
© Jim Gray, Andreas Reuter
c) Sub-transaction N has committed
and has installed its compensation
transaction CN that will get started
Transaction Processing - Concepts and if
Techniques
WICS commit.
August 2 - 6, 1999
T aborts. CN must
42
Using Multi-Level Transactions I
T
SELECT ...
INS ERT ...
UPDA TE ...
SELECT ...

Insert tuple
Update page
© Jim Gray, Andreas Reuter
Insert
address
table
entry
Insert B-tree entry
Locate position
Insert entry
Split
Transaction Processing - Concepts and Techniques
page
WICS August 2 - 6, 1999
43
Using Multi-Level Transactions II
Original sequence of actions
Invocation :
Insert_Tuple (t,ret_code)
Find free page;
let the number be P
Read page P
Remove tuple t
Update page
header

Release database key K
Update free space information
Read page P
Update the page
header
Insert tuple t
Grab free database key K
Insert K into page header of page P
into entry pertaining to t
Read page containing entry for
database key value K
Insert pointer to P into table entry
t
© Jim Gray, Andreas Reuter
Locate free space information for
page P
Update free space information
Remove K from t's page header
entry in page P
Read page containing entry for
database key value K
Remove pointer from table entry
Remember page number P
Invocation :
Remove_Tuple(K,ret_code)
Sequence of counter-actions
Transaction Processing - Concepts and Techniques
t
WICS August 2 - 6, 1999
44
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
45
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
46
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
47
Using Processing Context
SimpleProgram()
{ read (input_message);
BEGIN WORK;
/* perform computation on
input message and context */;
send (output_message);
COMMIT WORK;
};
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
Private
context

Global
context
WICS August 2 - 6, 1999
48
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
49
The Banking Application - Basic Idea
First, we have the Accounts relation:
Balance
Acct-No
Owner
1
Masha
12,345.80
2
Vijay
8,433.17
...
...
...
Second, we have a Restart relation:
Purpose
Last_OK_Acct
Date
Interest
0
19981031
...
...
...

Restart
Accounts
© Jim Gray, Andreas Reuter
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.
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
50
The Banking Application - Using
Transactional Restart
Here is the basic logic for updating 1,000,000 accounts in a restartable way:
while (true)
{ begin work;
select Last_OK_Acct into :LOA
from Restart where Purpose = “interest”;
Start the processing loop.
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 + 1000;
if LOA = 1000000 then LOA = 0;
Define the next restart point. When
everything is complete, reset to 0.
update Restart
set Last_OK_Acct = :LOA;
commit work;
if LOA = 0 then exit;
Next batch is done and restart point is set.
}
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
51
Sagas
A
B C
system
A
C
A
B
C
A
C
C
C
A
B
C

S3
S2
S1
A
A
C
B
A
C
trigger
trigger
A
B
C
A
CS2
CS1
A
C
B
C
A
C
trigger
© Jim Gray, Andreas Reuter
Transaction Processing - Concepts and Techniques
WICS August 2 - 6, 1999
52