; Ch 4. Transaction-Oriented Computing
Documents
User Generated
Resources
Learning Center
Your Federal Quarterly Tax Payments are due April 15th

# Ch 4. Transaction-Oriented Computing

VIEWS: 2 PAGES: 86

• pg 1
```									Transaction-Oriented Computing

COP 6730

1
The Temporary Update Problem
T1 (Transfer)    T2 (Deposit)   X Y     M   N
80 60   4   5
X := X - N;
Write(X);                       75 60   4   5
Recover(X);                     80 60   4   5   “temporary”
X := X + M;
value.
Write(X);      79 60   4   5
X := X - N;                                     •   X initially has \$80
Write(X);                       74 60   4   5   •   T1 transfers \$5 from X
Read(Y);                                        •   T2 deposits \$4 into X
Y := Y + N;                                     •   X should have \$79
Write(Y);                       74 65   4   5
Correct Answer                  79 65   4   5

2
The Lost Update Problem
T1 (Transfer)    T2 (Deposit)   X Y     M   N
80 60   4   5
This update     X = X - N;
X = X + M;     80 60   4   5
Write (X);
Read (Y);                       75 60   4   5
Write (X);     84 60   4   5
Y = Y + N;
Write (Y);                      84 65   4   5
Correct Answer                  79 65   4   5

Balance should be:
\$80 - \$5 + \$4 = \$79.
3
The Incorrect Summary Problem
T1 (Transfer)        T2 (Sum)     Sum W X Y
70 80 60
N
5
205  70 + 80 + 60
 Inconsistent !
Sum = 0;
Sum = Sum + W;   70   70 80 60   5
X = X - N;
Write(X);                          70   70 75 60   5
be processed
Sum = Sum + X;
efficiency.
Sum = Sum + Y;   205 70 75 60    5   However, they
Y = Y + N;
must have the
Write(Y);                          205 70 75 65    5   same results as in
Correct Answer:                    210 70 75 65    5   serial execution
4
Outline
• Atomic Action and Flat Transactions.

• Sphere of Control.

• Notations

• Transaction Models

5
ACID Properties
A transaction is a collection of actions with the
following ACID properties:
• Atomicity: A transaction’s changes to the state are
atomic – either all happen or non happen.
• Consistency: A transaction is a correct transformation
of the state.
• Isolation: Even though transaction execute concurrently,
it appears to each transaction, T, that other executed
either before or after T, but not both.
• Durability: Once a transaction completes successfully,
its changes to the state survive failures (transaction’s
effects are durable).
6
Transaction: Atomicity Property
• A transaction is an atomic sequence of actions (e.g.,

• Each transaction, executed completely, must leave the DB
in a consistent state if DB is consistent when the transaction
begins.
–   Users can specify some simple integrity constraints on the data, and
the DBMS will enforce these constraints.
–   Beyond this, the DBMS does not really understand the semantics of
the data. (e.g., it does not understand how the interest on a bank
account is computed).
–   Thus, ensuring that a transaction (run alone) preserves consistency
is ultimately the user’s responsibility!
Disk Writes as Atomic Actions (1)
Atomicity of a disk write operation would mean that
either the entire block is correctly transferred to the
specified slot, or the slot remains unchanged.
1.   Single disk write:
Problem: If there is a power loss in the middle of the
operation, it might happen that the first part of the block is
written, the the rest is not.

2. Read-after-Write: First issues a single disk
write, then reads the block from disk to verify
the correctness of the data.
8
Disk Writes as Atomic Actions (2)
3. Duplexed write: Each data block is written
to two places on disk
4. Logged write: The old contents of the block
are first read and then written to a different
place. Then the block is modified, and
eventually written to the old location

11
5

5
9
Disk Writes as Atomic Actions (3)

Observation:
• Even simple operations cannot simply be declared
atomic; rather,
• atomicity is a property for which the operations
have to be designed and implemented.

10
Action Types
• Unprotected Actions: They lack all of the ACID
properties except for consistency.
– Example: A single disk write.
• Protected Actions: They have the ACID properties.
– They do not externalize their result before they are
completely done (i.e., Isolation).
– They can roll back if anything goes wrong before the
normal end (i.e., Atomicity and Consistency).
– Once they have reached their normal end, what has
happened remains (i.e., Durability).
• Real Actions: These actions affect the real, physical
world in a way that is hard or impossible to reverse.
– Example: Firing a missile, dispensing money from an 11
ATM
Higher-Level Protected Actions
(Transactions)
Transaction (protected)
Since unprotected            Begin Work
actions can be undone,          unproted action
they can be included in         unproted action
a higher-level operation        unproted action
(i.e., transaction), which      unproted action
Commit Work
as a whole has the
ACID properties.
12
Handling Real Actions
The higher-level operation must make sure that the real
actions are executed only if all enclosing protected actions
have reached a state in which they will not decide to roll
back
BEGIN_WORK
SELECT … /*unprotected action*/
UPDATE … /*unprotected action*/
DRILL_HOLE …                        Defer execution
of real action
INSERT …
SELECT …
Now do it
IF (Condition) COMMIT_WORK;
ELSE              ROLLBACK_WORK;               Don’t do it at all

Note: The ACID properties hold for everything executed between
BEGIN_WORK and COMMIT_WORK.
13
Concurrency Control
• Concurrent execution of user programs is
essential for good DBMS performance.
–   Since disk accesses are frequent and relatively
slow, it is important to keep the cpu humming by
working on several user programs concurrently.
• Interleaving actions of different user programs
can lead to inconsistency: e.g., check is cleared
while account balance is being computed.
• Transaction processing ensures such problems
do not arise: users can pretend they are using
a single-user system.
Scheduling Concurrent Transactions
DBMS ensures that execution of {T1, ... , Tn} is
equivalent to some serial execution T1, ... Tn.
–   Before reading/writing an object, a transaction
requests a lock on the object, and waits till the
DBMS gives it the lock.
–   All locks are released at the end of the
transaction. (Strict 2PL locking protocol.)
I have    I can lock         I am
I wait                                   now
the lock                      done

T2   W
X   R
T1          T2    W
X   T1
2PL Locking Protocol
What if I need
Strict 2PL
Number of locks acquired

2PL                 the lock again
before commit ?

Time

• 2PL offers more concurrency; but it is difficult
to implement

I wait                                     I have the lock
for X                  X                       on X
W3       R2
T2                           T1

I have the lock         W1                 W4         I wait
on Y                         Y                    for Y

A solution: T1 or T2 is aborted and restarted
Ensuring Atomicity
• DBMS ensures atomicity (all-or-nothing
property) even if system crashes in the middle of
a transaction.
• Idea: Keep a log (history) of all actions carried
out by the DBMS while executing a set of Xacts:
–   Before a change is made to the database, the
corresponding log entry is forced to a safe location.
(WAL protocol; OS support for this is often
–   After a crash, the effects of partially executed
transactions are undone using the log. (Thanks to
WAL, if log entry wasn’t saved before the crash,
corresponding change was not applied to database!)
A Flat Transaction Example:
Debit/Credit (1)
exec sql CREATE TABLE accounts(
Aid      NUMERIC(9),
Bid      NUMERIC(9) FOREIGN KEY REFERENCES branches,
Abalance       NUMERIC(10),
filler   CHAR(48),
PRIMARY KEY (Aid);

accounts
Aid             Bid          Abalance     filler
19
A Flat Transaction Example:
Debit/Credit (2)
/*** main program with the invocation environment                                           */
/* global declarations*/
exec sql BEGIN DECLARE SECTION;        /* declare working storage                       */
long Aid, Bid, Tid, delta, abalance;   /* account id, branch id, teller id, debit or    */
/* credit amount, account balance                */
exec sql END DECLARE SECTION;          /* front end for the transaction program         */
DCApplication()                        /*                                               */
{read input msg;                       /* deal with request messages                    */
exec sql BEGIN WORK;              /* start the flat transaction                    */
Abalance = DoDebitCredit(Bid, Tid, Aid, delta); /* invoke transaction program      */
send output msg;                  /* send response to terminal                     */
exec sql COMMIT WORK;             /* successful end of transaction                 */
}    /*                                */
20
A Flat Transaction Example:
Debit/Credit (3)
/* subroutine for doing the database accesses defined for TPC debit/credit transaction

long DoDebitCredit(long Bid, long Tid, long Aid, long delta)
{
exec sql UPDATE accounts                    /* apply delta to the account balance
SET Abalance = Abalance + :delta   /*                                              */
WHERE Aid = :Aid;                  /*                                              */
exec sql SELECT Abalance INTO :Abalance        /* read new value of balance                    */
FROM accounts                      /*                                              */
WHERE Aid = :Aid                   /*                                              */
exec sql UPDATE tellers                        /* apply delta to teller balance                */
SET Tbalance = Tbalance + :delta   /*                                              */
WHERE Tid = :Tid;                  /*                                              */
exec sql UPDATE branches                       /* apply delta to branch balance                */
SET Bbalance = Bbalance + delta    /*                                              */
WHERE Bid = :Bid;                  /*                                              */
exec sql INSERT INTO history (Tid, Bid, Aid, delta, time)   /* insert parameters of transaction */
VALUES (:Tid, :Bid, :Aid, :delta, CURRENT)      /* into application history        */
return(Abalance);
}                                                                                                 21
ROLLBACK Statements
DCApplication()                                          /*                                   */
{          receive input message;                        /* deal with request messages        */
exec sql BEGIN WORK;                          /* start the flat transaction        */
Abalance = DoDebitCredit(Bid, Tid, Aid, delta); /* invoke transaction program      */
if (Abalance < 0 && delta < 0)                /* check if it a debit and account overdrawn */
{         exec sql ROLLABCK WORK; }          /* if so: don’t do it                */
else                                          /* this the good case: either credit or */
{                                            /* enough money in account           */
send output message;               /* send response to terminal         */
exec sql COMMIT WORK;              /* successful end of transaction     */
}
}

ROLLBACK makes sure that all the records are
returned to their Previous states.
22
Limitations of Flat Transactions (1)
A one-layer control structure will not be able to model
application structures that are significantly more
complex.

Example1:    Trip Planning
• If there are no direct flights between two places, we
must book a number of connecting flights.
• If a partially done travel plan is not acceptable, there
is no need to give back the reservation on all the
flights.
Note: Partial rollback is not possible for flat transactions.
23
Limitations of Flat Transactions (2)
•   At the end of a month, a bank has to modify
all of its accounts by crediting or debiting the
accumulated interest.
•   If the database process crashes after a large
number of accounts have been updated,
undoing these effects is undesirable.

Note: Partial commit is useful here.

24
SPHERES OF CONTROL

Spheres of Control (SoC) are based
on a hierarchy of abstract data types

25
Two Varieties of
SPHERES OF CONTROL
 One is statically established by structuring
the system into a hierarchy of ADTs.
 The other results from dynamic interactions
among SoCs on shared data, which cannot be
committed yet.
Predefined hierarchy
of functions
S               A2
Dynamic interaction    A1         B2                          B3
C1
B1                                     B4
C2                          B5
Dynamically created
for controlling the                                   D
commitment of A1                   D is a noncommitable data item.        26
Structural Dependencies in
Transaction Models
Structural dependencies reflect the hierarchical
organization of the system into ADTs of increasing
complexity.
Example: The commit of B3 depends on the commit of A2. The
reason is that A2 appears as an atomic action to the outside.

S                   A2
B2                                  B3
A1
C1
B1                                               B4
C2
B5
D
D is a noncommitable data item.          27
Dynamic Dependencies in
Transaction Models
Dynamic dependencies arise from the use of
shared data.
Example: A2 depends on A1 in the sense that A2 can
commit only if A1 does.
Dynamically created for
controlling the
commitment of A1
S                    A2
B2                                 B3
A1
C1
B1                                             B4
C2
B5
D
D is a noncommitable data item.                      28
Dynamic Behavior of SoC (1)
1. Beginning of scenario: At time t, a problem is
discovered in the SoC B. Data from D1 is determined
to be the case of the problem.

time                         t          29
Dynamic Behavior of SoC (2)
2. Tracing dependencies backward in time:
• A dynamic SoC, F, is extended backward in time to contain
the SoC that created the invalid data item D1.
• F serves as the recovery environment.

Recovery
environment
30
Dynamic Behavior of SoC (3)
3. Again going forward in time to do recovery:
 The recovery SoC, F, is expanded forward in time.
 F must encompass all processes that have become dependent
on any data produced by the process that created D1.

Note: Execution history
must be kept for as long
as control might still need
to be exercised

31
State-Transition Diagram for
a Flat Transaction
– Flat transactions can be described as state machines,
BEGIN WORK
NULL                  active
ROLLBACK
terminate                       WORK

committed                aborted

– When describing phenomena for which it is not
possible to define a prior a fixed number of states,
this approach is not appropriate.
– We will adapt the SoC model for describing
transaction models.                                32
Describing Transaction Models
Transaction models are distinguished by
different sets of rules
• for creating the events that drive atomic
actions, and
• for the conditions under which the rules
can take effect.

33
Describing Transaction Models - Example
Dynamically created for
controlling the
commitment of A1
S                A2
B2                               B3
A1
C1
B1                                          B4
C2
B5
D
D is a noncommitable data item.

• The event ROLLBACK WORK for atomic action B3
can be triggered by the program running inside B3, or
by the abort of A2
• The signal COMMIT WORK for B3 is not sufficient to
actually commit B3, that can only happen if the
condition “A2 is ready to commit” is also true.
34
Graphical Notation for
Transaction Models
Signal entries for the                  Begin
atomic action to perform                        Commit
a state transition
Abort

A       B     C       State indicator of the
action’s outcome
T
A        C
Eternally unique identifier
of the atomic action
Aborted            Committed
Each instance of an atomic action is depicted as a box with
• three entries at the top representing the signals for state
transitions the action can receive, and
• two entries at the bottom representing the two (mutually
exclusive) final outcomes of the action.                                     35
Describing Flat Transactions
A      B      C                            A     B      C                         A     B      C
System                                     System                                 System
A            C                             A        C                              A       C

Trigger

A      B      C                            A     B      C       Final             A     B      C
T                                         T              state                   T
A            C                             A        C                              A       C

a) Transaction T is active:             b) Termination scenario 1:                   c) Termination scenario 2:
An abort of the system                  Transaction T has committed; all             Same as scenario 1, but T
transaction will cause it to            of its event ports are deactivated;          assumes the final abort
roll back, too.                         the final state is highlighted.              sate.

Incoming port that cannot receive events, or final state that cannot be assumed

A flat transaction is an atomic action with only one structural dependency:
• If the system transaction aborts, the flat transaction is forced to abort, too.
• The system transaction is always in the active state, never commits, and aborts only as a result of a
system crash.
• Once a flat transaction has committed, it stays around without any dependencies, only documenting
which final result is relate to its name.                                                                   36
Defining Transaction Models
by Rules (1)
<rule id>: <precodition> → <rule modifier list>,
<signal list>,
<state transition>.

• The <rule id> specifies the signal port
this rule is for.
• This rule is not activated until the
Wait     preconditions are fulfilled
Precondition
37
Defining Transaction Models
by Rules (2)
<rule id>: <precodition> → <rule modifier list>,
<signal list>,
<state transition>.

• <rule modifier list> is used to introduce
additional arrows as they are needed, or to
A     B
System
C
delete arrows that have become obsolete.
A         C
<rule modifier> ::= +(<rule id>|<signal>)
Trigger
modifier>
<rule (system)|S (T)) ::= - (<rule id>|<signal>)
+(SA
<rule modifier> ::= delete(x), x is an atomic action.
A
A     B       C
T
A         C         <signal> is the name of the rule to be activated by the signal
38
Defining Transaction Models
by Rules (3)
<rule id>: <precodition> → <rule modifier list>,
<signal list>,
<state transition>.

• <signal list> describes which signals are
generated as part of the state transition.
(The signals are simply the names of rules
that are to be activated by the signal).
• <state transition> is essentially redundant,
but it is kept for clarity.
39
Rules for Flat Transactions
A     B       C                             A     B      C                          A     B      C
System                                      System                                  System             Remove
A       C                                  A        C        Remove                 A       C            the rules
the rules
Trigger

A     B       C                             A     B      C                          A     B      C
T                                           T                                       T
A       C                                  A        C                               A       C
a) Transaction T is active:           b) Termination scenario 1:                   c) Termination scenario 2:
Abort of the system transaction       Transaction T has committed; all of its      Same as scenario 1, but T
will cause it to roll back, too.      event pots are deactivated; the final        assumes the final abort sate.
state is highlighted.

SB(T):         +(SA(system)|SA(T)), , BEGIN WORK
SA(T):         (delete(SB(T)), delete(SC(T))), ,ROLLBACK WORK
SC(T):         (delete(SB(T)), delete(SA(T))), ,COMMIT WORK
•     The first rule establishes the dependency from the system transaction
and then starts the flat transaction itself.
•     The other rules specify the effects of the abort and commit events –
since both resulting states are final states, the rules pertaining to the
terminated transaction must be removed.                                 40
Flat Transaction with Savepoints (1)
BEGIN WORK
(get transaction started) implicit
SAVE WORK: 1
Action                  Work “covered” by savepoint
Action                  number 2

SAVE WORK: 2
Action                                   Action       Work “covered” by savepoint
SAVE WORK: 3                                  Action       number 5

Action                               SAVE WORK: 5
Action                                   Action
Action                               SAVE WORK: 6
SAVE WORK: 4                                  Action
Action                                   Action
ROLLBACK WORK (2)                              SAVE WORK: 7
Action                        Action
Action                        Action
ROLLBACK WORK (7)               SAVE WORK: 8
Action

undone                                                          COMMIT WORK

41
Flat Transaction with Savepoints (2)
• A savepoint is established by invoking the SAVE
WORK function, which causes the system to record
the current state of processing.
– This returns to the application program a handle
that can subsequently be used to reestablish
• A ROLLBACK does not affect the savepoint counter.
– Advantage: Increasing Numbers monotonically allows the
complete execution history to be maintained.
There is nothing that prevents the application program, after
having generated savepoint number 8, from requesting a
rollback to savepoint 4 (see next slide).
42
Unstructured Program
There is nothing that prevents the application
BEGIN WORK
(get transaction started) implicit
SAVE WORK: 1                 program, after having generated savepoint
Action                  number 8, from requesting a rollback to
Action                  savepoint 4.
SAVE WORK: 2
Action                           Action
SAVE WORK: 3                          Action
Action                        SAVE WORK: 5
Action                           Action
Action                        SAVE WORK: 6
SAVE WORK: 4                          Action
Action                           Action
ROLLBACK WORK (2)                       SAVE WORK: 7
Action                     Action
Action                     Action
ROLLBACK WORK (7)             SAVE WORK: 8
Action

undone                                              ROLLBACK WORK (4)

43
Graphical Representation of
the Savepoint Model (1)
• The basic idea is to regard     A     B       C

the execution between two
System
A          C

consecutive savepoints as an        Trigger

atomic action in the sense of   A     B       C
SoC.                                  S1
A          C

• The completion of a savepoint       Trigger

creates a new atomic action     A     B       C

that is dependent on its              S2

predecessor.
A          C

44
Graphical Representation of the
Savepoint Model (2)
A     B       C                          A     B       C                             A        B     C
System                                   System                                       System
A         C                               A        C                                     A        C

Trigger                                  Trigger                                      Trigger

A     B       C                          A     B       C                             A        B     C
S1                                       S1                                             S1
Trigger
A         C                               A        C                                     A        C

a) Transaction has started,                          Trigger           Trigger                    Trigger
establishing savepoint 1.
A     B       C                             A        B     C
S2                                             S2
A        C                                     A        C

b) Next savepoint, S2, has                               Trigger                     Trigger
been taken.

A        B     C
Forbidden state or event                                      c) Next savepoint, S3,             S3
has been taken.                             45
A        C
The Rules for Savepoint Model
First Savepoint, S1:
SB(S1) :           +(SA(system)|SA (S1)), ,
BEGIN WORK
SA(ST) : (ST<S1)  , , ROLLBACK WORK
SC(S1) :           , , COMMIT WORK
SS(S1) :           +(SA(S1)|SA (S2)), SB(S2).

(2) +(SA(S1)|SA(S2))
ST: The target savepoint
(1) SB(S2)
of the rollback

Note:
• The delete clauses in the abort and commit rules look exactly like
in the case of flat transactions, and are omitted here.
46
The Rules for Savepoint Model
First Savepoint, S1:
SB(S1) :           +(SA(system)|SA (S1)), ,
BEGIN WORK
SA(ST) : (ST<S1)  , , ROLLBACK WORK
SC(S1) :           , , COMMIT WORK
SS(S1) :           +(SA(S1)|SA (S2)), SB(S2).

Intermediate Savepoint, Sn:
SB(Sn) :           , , BEGIN WORK
SA(ST) : (ST<Sn)  , SA(Sn-1), ROLLBACK WORK
SC(Sn) :           , SC(Sn-1), COMMIT WORK

SS(Sn) :           +(SA(Sn)|SA (Sn+1)), SB(Sn+1).

ST : The target savepoint of the rollback

Note:
• The delete clauses in the abort and commit rules look exactly like
in the case of flat transactions, and are omitted here.
• During a rollback, all the atomic actions on the way back are                    47
aborted.
Limitation of Savepoint
• All savepoints perish in case of a
system crash
• A solution is to make savepoints
persistent
the state of the transaction must be kept in
durable (persistent) storage.

48
Persistent Savepoints
Restart Strategy
• The last unfinished savepoint interval is
roll back, but
• the state as of the previous successful
persistent savepoint is reestablished.
Potential Issue: Conventional programming languages
do not understand transactions:
• the data contents will return to the state as of the
specified savepoint, but
• the local programming language variables will not. 49
CHAINED TRANSACTIONS
• Chained transactions are modeled by a
sequence of atomic actions, executed one at
a time.
• Each transaction behaves like a flat
transaction (i.e., no rollback after commit)
• The commitment of one transaction and the
beginning of the next are wrapped together
into one atomic operation.
 The database content remains intact across the
transaction boundaries.
Effect: The amount of work lost after a crash can
be minimized.
50
Rules for Chained Transactions
a) The first transaction in
A       B       C                 A       B       C                 A       B       C      the chain has been
System                                C1                                C2             started.
A             C                 A               C                 A               C   b) Start of the second one
will be triggered by
Trigger                                   Trigger
commit of the first one.

c) The first transaction in the
A       B       C                 A       B       C                 A       B       C
chain has been committed;
System                            C1                                C2
the second one got
A           C                     A           C                     A           C              started as part of commit
of C1. Now the second one
Trigger                                                                is structurally dependent on
“system”.

SB(Cn): +(SA(system)|SA (Cn)),, BEGIN WORK
SA(Cn): (delete(SB(Cn)), delete(SC(Cn))),, ROLLBACK WORK
SC(Cn): …,SB(Cn+1), COMMIT WORK                                                                                  51
Chained Transaction v.s. Savepoints
• Since the chaining step irrevocably completes a
transaction, rollback is limited to the currently
active transaction
• The COMMIT allows the application to free locks
that it does not later need.
• After a crash, the entire transaction is rolled back
irrespective of any savepoints taken so far. The
chained transaction schemes, on the other hand, can
reestablish the state of the most recent commit.
Committed                                Active
transaction                           transaction

A     B      C           A     B    C             A   B    C
System                     C1                     C2
A        C               A         C             A        C

52
Trigger                            Trigger
Restart Processing in
Chained Transactions
From the application’s point of view, the whole chain is likely to be
the sphere of control. What should actually happen in case one of
the transactions in the chain aborts?
Abort: the application has to determine how to fix that.

commit
A     B      C             A   B    C
System                     C1
A        C                A        C

A   B    C
Trigger
C2
A        C

53
Restart Processing in
Chained Transactions
From the application’s point of view, the whole chain is likely to be
the sphere of control. What should actually happen in case one of
the transactions in the chain aborts?
Abort: the application has to determine how to fix that.
Crash: the last transaction, after having been rollback, should
be restarted.

A      B       C          A        B      C           C1’ is the new instance of C1
System                         C1
Trigger
A           C            A             C

Trigger                       New instance
Trigger                                      of C1 starts
over again               A   B    C
Trigger
C2

A      B      C            A        B        C                     A        C

Restart                        C1’
Trigger                              54
A        C                   A          C
Chained Transaction vs. Savepoints

Persistent          Chained
Savepoints         Savepoints        Transaction
Any previous       Any previous         Limited to
Rollback       savepoint          savepoint        currently active
transaction

Entire        Reestablish most   Reestablish the
Recovery      transaction is    recent savepoint    state of most
rolled back                         recent commit

Locks kept until   Locks kept until
Concurrency     transaction        transaction      Free locks early
commit             commit

55
Nested Transactions
• A nested transaction is a tree of subtransactions.
• A subtransaction can either commit or rollback.
– Its commit takes effect only if the parent transaction commits.
– Any subtransaction can finally commit only if the root transaction commits.

Starting at the root. each transaction can create lower-level subtransactions, which are
embedded in the sphere of control of the parent. Transactions at the leaf level are flat   56
transactions, except that they lack the durability of non-nested flat transactions.
Nested Transaction - SOC
Its commit takes
effect only if the
parent transaction
commits
T2111
T211
Any subtransaction                     T2112
can finally commit only
if the root transaction
commits           T21

T2121
T1               T212
T2122

T221
T22
T222
57
Behavior of Nested Transactions
Commit & Rollback
Commit rule: The commit of a subtransaction
makes its results accessible only to the
parent transaction.

Rollback rule: The rollback
of a subtransaction
causes all of its
subtransactions to
rollback.
– Subtransactions have only
A,C, I, but not D.                        58
Behavior of Nested Transactions
Visibility Rule
• All changes done by a subtransaction become
visible to the parent transaction upon the
subtransaction’s commit.

• All objects held by a parent transaction can
be made accessible to its subtransactions.

• Changes made by a subtransaction are not
visible to its siblings, in case they execute
concurrently.
59
Rules for Nested Transactions
System
System
System
A        B   C
A       B    C
A     B    C                                                                    T
T
T                                                                 A           C
A            C
A       C
Trigger
Trigger                 Wait
Trigger
a) Root                                          Wait
transaction T is                                         A       B        C                   A   B    C
running.                     A       B        C                  T1                               T2
T1                   A            C                      A        C
A        C
Wait
c) T1 has created
A        B        C                         subtransaction T11, and
b) Subtransaction T1                                                        after that the root
T11
has been started.                                          Wait          transaction starts another
subtransaction, T2.
Tk is the parent of Tkn                                             A            C

SB(Tkn):          +(SA(Tk)|SA (Tkn)),, BEGIN WORK
Note: The arrows labeled “wait”
SA(Tkn):          , , ROLLBACK WORK                                          correspond to the precondition
Sc(Tkn): C(Tk)  , , COMMIT WORK                                              clauses in the rules.     60
Using Nested Transaction
Strong relationship between
modularization in software
engineering and the nested
transaction mechanism.
– Modular design takes care
of the application structure
and encapsulates local
(dynamic) data structures;
– the transactions make sure
that the global data used
by these modules are
isolated and recover with
the same granularity.

Note: Database is a very
large global variable
61
Transactional C
• Transactional C (IBM) is a
programming language supported by
the Encina TP monitor.
• The run-time system of Transactional
C supports the notion of nested
transactions.

62
Emulating Nested Transaction
by Savepoints
Savepoint generated
at beginning of
each subtransaction

Rollback to savepoint
s121 has the effect
of aborting Tk121

Strategy:
• A savepoint is generated at the beginning of each subtransaction
• rolling back to a savepoint has the same effect as an abort of the
corresponding subtransaction.                                                    63
Limitations of the Emulation of
Nesting by Savepoints (1)
• The emulations is limited to systems where everything
within a top-level transaction is executed sequentially.
Reason:
– If subtransactions are allowed to execute in parallel,
the nesting order will no longer be monotonically
mapped onto the sequence of savepoints.
– Reestablishing the state of
the savepoint associated
with a transaction can
affect arbitrary
subtransactions, rather then
only the subtree of the
aborting subtransaction.

64
Limitations of the Emulation of
Nesting by Savepoints (2)
• In nested transactions, subtransactions inherit locks
from their parent transactions, and parent transactions
counter-inherit locks acquired by their subtransactions.
This mechanism cannot be emulated by savepoints.
Reason: There is only one flat transaction in using savepoints.

65
Distributed Transactions
• A distributed transaction is typically a flat transaction
that runs in a distributed environment.
• The decomposition into distributed transactions does
not reflect a hierarchical structure in the programs to
be executed, but is induced by the placement of the
data in the network.
• In a distributed transaction, if a subtransaction
commits, it forces all other subtransactions to commit.
Note: By comparison, in a nested transaction, this is simply a
local commit of that subtransactions.

• Distributed subtransactions normally cannot roll back
independently. Their decision to abort affects the
entire transaction.
66
Multi-Level Transactions
A     B       C               A        B       C               A     B      C
System                        System                           System
A         C                  A                C               A         C
c) Subtransaction N has
committed and has
Trigger                                                                                installed its
Trigger                       Trigger
compensation
transaction, CN, that will
A     B       C               A        B       C               A     B      C
get started if T aborts.
T                                T                             T                     CN must commit.
A         C                  A                C               A         C

a) Root transaction T                  Trigger                                     Trigger
is running.

A        B       C   A   B   C                A       B   C
b) Subtransaction                                N                         CN
N
N has been
started.             A                C   A       C                 A          C

•   CN is the compensating transaction corresponding to the subtransaction
N. It can semantically reverse what N has done.
•   N can commit independently of T. When it does so, however, CN enters
the scene.
•   The abort of T is unconditionally linked to the commit of CN         67
(i.e., CN must not fail.)
Multi-Level Transactions vs
Nested Transactions
Nested transaction
System
Multi-level transaction
T2 does not have
the durability              A     B      C
A        B   C                           property                      System
T
A         C
A           C

Trigger
Trigger
Trigger            Wait
Precommit: N has       A     B      C
A       B        C                   A   B    C            the durability             T
T1                               T2                  property           A         C
A            C                      A        C
Trigger
Wait
A    B   C                A       B    C
A        B        C                                                         N                         CN
T11                                                             A       C                 A          C
Wait
A            C
68
Rules for Multi-Level Transactions
• Rules for subtransaction N:
SB(N):  , , BEGIN WORK
SA(N):  , , ROLLBACK WORK
SC(N):  +(SA(T)|SB(CN)), , COMMIT WORK

• Rules for the compensating translation
CN:
SB(CN):  +(SC(restart)|SB(CN’)), , BEGIN WORK
SA(CN):  , SB(CN’), ROLLBACK WORK
SC(CN):  delete(CN’), , COMMIT WORK
Restart: A system restart transaction runs after an abort
caused by some internal malfunction
Note: CN’ is an instance of CN. It ensures that
the compensation continues after restart.
69
Multi-Level Transactions
nested transactions with the ability to
precommit the results of subtransactions,
and therefore improve concurrency.

• Disadvantage: The compensation actions can
be very expensive.

Note: Since rollback is not frequent, the advantages of
having smaller units of commitment control outweigh
the cost of compensation.
70
Transaction Processing Context
Programs frequently use contextual
information in addition to the input
parameters; this information is called
context and is (potentially) modified
every time the program is invoked.

f(input_message, context) 
{output_message, context}

71
Transaction Processing Context
Example
a      b     c    d
exec sql declare cursor x                      3                 10
select a, b, c                   x     7
9
10
10
from      rel_a                        12                10
16                10
where d = 10                           21                10
order by a ascending;
open cursor x;
do { exec sql fetch next x into :a, :b, :c;    :a     :b    :c
/* perfrom computation */
} while (sqlcode == 0);
exec sql close cursor x;
Computation

Private context: The cursor position is a context that is
private to the program.
Global context: The contents of the database itself
determines which “next” tuple can be retrieved.               72
COMPUTE INTERESTS
• If all accounts are updated within one
transaction, there is no need for
maintaining context
Reason: If it fails, the same thing can be done
over again (i.e., it is context-free)

• Splitting the job up into a sequence of
transactions requires keeping context in
durable memory
73
COMPUTE INTERESTS
ComputeInterest ()
for (account_no = 1; account_no <= 1,000,000; account_no++)
{SingleAccount(interest_rate, account_no);}
};
The surrounding program needs
SingleAccount (interest_rate, account_no)            to keep the context just in case
{ BEGIN WORK                                       something happens along the way
/*do account update*/
COMMIT WORK;
return (“OK”);
}                              This transaction is context-free
Because the next account number
is passed in the input message                      74
DURABLE CONTEXT
Context can be volatile or durable:
– An end-of-file pointer is volatile context
because it needs not be recovered.

– The context that says how far the
sequence of ComputeInterest transactions
has gotten must be durable because the
program (reinstantiated version) and the
database are out of synch after a crash.
75
THE MINI BATCH (1)
A solution to the ComputeInterest problem:
– Executing a sequence of transactions, each of
them updating only a small number of accounts
(called mini batch).
– The application maintains its context as a
database record.
Accounts               |              |

0 1    …               n-1 n n+1 … i       stepsize    …

Last_account_done
PROCESS
Note: Isolation is guaranteed
BATCHCONTEXT    n-2                        only for the tuples the step
Database    transaction is accessing. 76
THE MINI BATCH (2)
while (last_account_done < max_account_no)
{ EXEC SQL BEGIN WORK;            /* initiate next mini-batch */
EXEC SQL UPDATE accounts             /* compute current mini-batch */
SET        account_total = account_total * (1+interest_rate)
WHERE      account_no
BETWEEN :last_account_done + 1 AND
:last_account_done + :stepsize;
EXEC SQL UPDATE batchcontext              /* update context */
SET        last_account_done = last_account_done + stepsize;
EXEC SQL COMMIT WORK;
last_account_done = last_account_done + stepsize; /* next mini-batch */
}
Accounts              |               |

0 1     …              n-1 n n+1 … i      stepsize    …

77
Mini-batch is not Strictly Atomic
• Mini-batch does not achieve strict
atomicity for the entire computation
• Nevertheless, it is suitable for the
ComputeInterest application because the
interests must eventually be computed
(i.e., transaction eventually commits)
• Commit cannot always be guaranteed for
other types of long-lived transactions
– Examples include many engineering design and
office automation applications                 78
LONG-LIVED TRANSACTIONS
General Requirements
1. Minimize lost work: It must be possible to split up
bulk transactions in order to control the amount of
lost work in case of a system crash.

2. Recoverable computation: There must be ways to
temporarily stop the computation without having to
commit the results (ACID has no notion of
“suspending” a transaction).

3. Explicit control flow: Under all failure conditions, it
must be possible to either proceed along the
prespecified path or remove from the system what
has been done so far.
79
SAGAS
Saga is an extension of the notion of
chained transactions.
1. It defines a chain of transactions as a
unit of control.

2. It uses the compensation idea from
multi-level transactions to make the
entire chain atomic.

80
SAGAS - Properties
• Commit case:                  S1, S2, …, Si, … , Sn-1, Sn

• Rollback scenario:
S1, S2, …, Sj(abort), CSj-1… , CS2, CS1

A     B C        A   B    C        A   B     C         A   B    C
System           S1                S2                  S3
A       C        A        C        A         C         A        C

Trigger                                     Trigger   A backward chain of
A    B C          A   B     C             compensating transactions
CS1               CS2                 is established as the
A        C        A         C             original chain proceeds in a
forward direction.
Trigger                               81
COOPERATING TRANSACTIONS
(1)
Cooperative transactions allow for explicit
interactions among collaborating users on
shared (design) object.
show me            Use                   Give
object X         object X               back X
Transaction A    do some design work

P re lim in a ry ,
X                        m u s t no t
be m o d ifie d

Transaction B
create object X              granted
B m a y re s u m e
Time                                    co m p u ta tio n
on X                        82
COOPERATING TRANSACTIONS (2)
• Prerelease upon request:
– object X is isolated until the surrounding SoC has decided to
commit.
– However, there may be special transactions that are allowed
to access it without creating a commit dependency on it.

• Explicit return:
A transaction T that selectively releases commitment control
knows:
– what kind of access is requested to the object, and
– T gets informed as soon as the object is returned to its
original SoC.                                              83
Transaction Models
Single layer
Can rollback
Flat         of control
to a                    transaction
savepoint

Persistent                       Chained
Savepoints                savepoints                     transaction

Reestablish            Free locks
last savepoint              early
after recovery

84
Transaction Models
Flat
transaction

Persistent                Chained
Savepoints                savepoints              transaction

Nested             Multilevel
Transaction         Transaction             SAGAS

Supports          Precommit allows        Chained transaction
modularization        early release         with compensating
in software            Of locks               transactions
engineering
85
Transaction Models
I know how
Transaction 2
uses “X”

Transaction
1                  Cooperating
Transaction

Transaction
2
May I
Use “X”
I am done
with “X”

86

```
To top