View
214
Download
0
Category
Tags:
Preview:
Citation preview
1
Transaction-Oriented Computing
COP 6730
2
The Temporary Update Problem
T1 (Transfer) T2 (Deposit) X Y M N80 60 4 5
Read(X);X := X - N;Write(X); 75 60 4 5
Read(X);T1 failsRecover(X); 80 60 4 5
X := X + M;Write(X); 79 60 4 5
Read(X);X := X - N;Write(X); 74 60 4 5Read(Y);Y := Y + N;Write(Y); 74 65 4 5Correct Answer 79 65 4 5
Problem: T2 reads the invalid “temporary” value.
X=80
Y=60
Transfer $5
Deposit $4
Balance should be: $80 - $5 + $4 = $79
3
The Lost Update Problem
This update is lost
Balance should be: $80 - $5 + $4 = $79.
X=80
Y=60
Transfer $5
Deposit $4
4
The Incorrect Summary Problem
T1 (Transfer) T2 (Sum) Sum W X Y N70 80 60 5
Sum = 0;Read(W);Sum = Sum + W; 70 70 80 60 5
Read(X);X = X - N;Write(X); 70 70 75 60 5
Read(X);Sum = Sum + X;Read(Y);Sum = Sum + Y; 205 70 75 60 5
Read(Y);Y = Y + N;Write(Y); 205 70 75 65 5Correct Answer: 210 70 75 65 5
205 70 + 80 + 60
Inconsistent !
Transactions can be processed concurrently for efficiency. However, they must have the same results as in serial execution
W X Y
5
Outline
• Atomic Action and Flat Transactions.
• Sphere of Control.
• Notations
• Transaction Models
6
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).
A transaction is a collection of actions with the following ACID properties:
Transaction: Atomicity Property
• A transaction is an atomic sequence of actions (e.g., read/write database).
• 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!
8
Disk Writes as Atomic Actions (1)
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.
Problem: There is no provision to return to the initial state.
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.
9
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
Disk Writes as Atomic Actions (2)
511
5
RAM
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
Disk Writes as Atomic Actions (3)
11
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
ATM
12
Higher-Level Protected Actions (Transactions)
Since unprotected actions can be undone, they can be included in a higher-level operation (i.e., transaction), which as a whole has the ACID properties.
unproted action
unproted action
unproted action
unproted action
Transaction (protected)
Begin Work
Commit Work
13
Handling Real ActionsThe 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 …
INSERT …
SELECT …
IF (Condition) COMMIT_WORK;
ELSE ROLLBACK_WORK;
Defer execution of real action
Now do it
Don’t do it at all
Note: The ACID properties hold for everything executed between BEGIN_WORK and COMMIT_WORK.
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 TransactionsDBMS 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 2-Phase locking protocol)
X T1T2 RW
I have the lockI wait
X T1T2 W
I am done
I can lock now
2PL Locking ProtocolN
umbe
r of l
ocks
acq
uire
d
Time
What if I need the lock again
before commit ?
Strict 2PL2PL
• 2PL offers more concurrency; but it is difficult to implement
Deadlock
X
T1T2
R2W3
I have the lock on X
I wait for X
A solution: T1 or T2 is aborted and restartedA solution: T1 or T2 is aborted and restarted
YW4W1I have the lock on
YI wait for Y
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:– Write-Ahead Log (WAL) Protocol: Before a change is
made to the database, the corresponding log entry is forced to a safe location. (OS support for this is often inadequate.)
– Rollback: After a crash, the effects of partially executed transactions are undone using the log.
Note: If log entry wasn’t saved before the crash, corresponding change was not applied to database!
19
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);
accountsAid Bid Abalance filler
20
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 */
} /* */
21
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);
}
22
ROLLBACK StatementsDCApplication() /* */
{ 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.
23
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.
24
Limitations of Flat Transactions (2)
Example 2: Bulk Updates
• 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.
25
SPHERES OF CONTROL
Spheres of Control (SoC) are based on a hierarchy of abstract data types (ADTs) which execute atomically
26
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.
B1C2
C1B3
B4B5
B2A1A2S
DD is a noncommitable data item.
Dynamically createdfor controlling the commitment of A1
Predefined hierarchyof functions
Dynamic interaction
27
Dependency in Transactions
• Structural Dependency• Dynamic Dependency
28
Structural Dependencies in
Transaction ModelsStructural 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.
B1C2
C1B3
B4
B5
B2A1
A2
D
S
D is a noncommitable data item.
S
29
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.
B1C2
C1B3
B4
B5
B2A1
A2
DD is a noncommitable data item.
S is dynamically created for controlling the commitment of A1
S is dynamically created for controlling the commitment of A1
30
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.
ttime
Problem
31
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.
t
Problem
Recoveryenvironment
F
ttime
Problem
32
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
F
33
State-Transition Diagram for a Flat Transaction
– Flat transactions can be described as state machines,
– 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.
NULL active
abortedcommitted
BEGIN WORK
ROLLBACK WORK
WORKCOMMIT
terminate
terminate
34
Describing Transaction Models
• for creating the events that drive atomic actions, and
• for the conditions under which the rules can take effect.
Transaction models are distinguished by different sets of rules
35
Describing Transaction Models - Example
Dynamically created for controlling the commitment of A1
B1C2
C1B3
B4
B5
B2A1
A2
D
S
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.
36
Graphical Notation for Transaction Models
A B C
T
A C
State indicator of the action’s outcome
Aborted Committed
Begin
Abort Commit
Signal entries for the atomic action to perform a state transition
Eternally unique identifier of the atomic action
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.
37
Describing Flat TransactionsA B C
System
A C
A B C
T
A C
a) Transaction T is active: An abort of the system transaction will cause it to roll back, too.
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.
A B C
System
A C
A B C
T
A C
A B C
System
A C
A B C
T
A C
b) Termination scenario 1: Transaction T has committed; all of its event ports are deactivated; the final state is highlighted.
c) Termination scenario 2: Same as scenario 1, but T assumes the final abort sate.
Incoming port that cannot receive events, or final state that cannot be assumed
Trigger
Finalstate
38
Defining Transaction Models by Rules (1)
• The <rule id> specifies the signal port this rule is for
• This rule is not activated until the preconditions are fulfilled
<rule id>: <precodition> → <rule modifier list>,
<signal list>,<state transition>.
Wait
Precondition
Signal port
SA(T1)
39
Defining Transaction Models by Rules (2)
• <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.
<rule id>: <precodition> → <rule modifier list>,
<signal list>,<state
transition>.A B C
System
A C
A B C
T
A C
Activate SA(T) is a signal from SA(System)
40
Defining Transaction Models by Rules (3)
• <rule modifier list> is used to introduce transactional dependencies as they are needed, or to delete dependencies that have become obsolete. <rule modifier> ::= +(<rule id>|<signal>) <rule modifier> ::= - (<rule id>|<signal>) <rule modifier> ::= delete(x), x is an atomic action.
<signal> is the name of the rule to be activated by the signal
<rule id>: <precodition> → <rule modifier list>,
<signal list>,<state
transition>.
A B C
System
A C
A B C
T
A C
Trigger+(SA(system)|SA(T))adds transactional
dependency !
41
<rule modifier list> vs <signal list>
<rule id>: <precodition> → <rule modifier list>,
<signal list>,<state transition>.
A B C
T1
A C
Signal port
SA(T1)
A B C
T1
A C
A B C
T2
A C
Signal port
SA(T1)
A B C
T1
A C
A B C
T2
A C
Trigger
SB(T2)SB(T2)
+(SA(T1)|SA(T2))+(SA(T1)|SA(T2))
Signal port
SA(T1)
42
Rules for Flat Transactions
SB(T): +(SA(system)|SA(T)), , BEGIN WORK
• The first rule establishes the dependency from the system transaction and then starts the flat transaction itself.
A B C
System
A C
A B C
T
A C
a) Transaction T is active: Abort of the system transaction will cause it to roll back, too.
A B C
System
A C
A B C
T
A C
A B C
System
A C
A B C
T
A C
b) Termination scenario 1: Transaction T has committed; all of its event pots are deactivated; the final state is highlighted.
c) Termination scenario 2: Same as scenario 1, but T assumes the final abort sate.
Trigger
Removethe rulesRemove
the rules
<rule id>: <precodition> → <rule modifier list>,
<signal list>,<state
transition>.
Note: No precondition, no signal list
43
Rules for Flat Transactions
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.
A B C
System
A C
A B C
T
A C
a) Transaction T is active: Abort of the system transaction will cause it to roll back, too.
A B C
System
A C
A B C
T
A C
A B C
System
A C
A B C
T
A C
b) Termination scenario 1: Transaction T has committed; all of its event pots are deactivated; the final state is highlighted.
c) Termination scenario 2: Same as scenario 1, but T assumes the final abort sate.
Trigger
Removethe rulesRemove
the rules
44
Flat Transaction with Savepoints (1)
BEGIN WORK(get transaction started) implicit
SAVE WORK: 1
Action
Action
SAVE WORK: 2
Action
SAVE WORK: 3
Action
Action
Action
SAVE WORK: 4
Action
ROLLBACK WORK (2)
Action
Action
SAVE WORK: 5
Action
SAVE WORK: 6
Action
Action
SAVE WORK: 7
Action
Action
ROLLBACK WORK (7)
Action
Action
SAVE WORK: 8
Action
COMMIT WORK
Work “covered” by savepoint number 5
Work “covered” by savepoint number 2
undone
45
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 (return to) that savepoint.
• A ROLLBACK does not affect the savepoint counter.
– Advantage: Increasing Numbers monotonically allows the complete execution history to be maintained.
– Disadvantage: It may lead to very unstructured programs. There is nothing that prevents the application program, after having generated savepoint number 8, from requesting a rollback to savepoint 4 (see next slide).
46
Unstructured ProgramBEGIN WORK
(get transaction started) implicit SAVE WORK: 1
Action
Action
SAVE WORK: 2
Action
SAVE WORK: 3
Action
Action
Action
SAVE WORK: 4
Action
ROLLBACK WORK (2)
Action
Action
SAVE WORK: 5
Action
SAVE WORK: 6
Action
Action
SAVE WORK: 7
Action
Action
ROLLBACK WORK (7)
Action
Action
SAVE WORK: 8
Action
ROLLBACK WORK (4)undone
There is nothing that prevents the application program, after having generated savepoint number 8, from requesting a rollback to savepoint 4.
“SAVE WORK: 4”
work never happended
“SAVE WORK: 4”
work never happended
47
Graphical Representation of the Savepoint Model (1)
• The basic idea is to regard the execution between two consecutive savepoints as an atomic action in the sense of SoC.
• The completion of a savepoint creates a new atomic action that is dependent on its predecessor.
A B C
System
A C
A B C
S1
A C
Trigger
A B C
S2
A C
Trigger DependencyDependency
SoC
Trigger
48
Graphical Representation of the Savepoint Model (2)
A B C
System
A C
A B C
S1
A C
Trigger
a) Transaction has started, establishing savepoint 1.
A B C
System
A C
A B C
S1
A C
Trigger
b) Next savepoint, S2, has been taken.
A B C
S2
A C
Trigger Trigger
A B C
System
A C
A B C
S1
A C
Trigger
A B C
S2
A C
Trigger
Trigger
A B C
S3
A C
Trigger Trigger
c) Next savepoint, S3, has been taken.
Forbidden state or event
49
The Rules for Savepoint Model
Note:
• The delete clauses in the abort and commit rules look exactly like in the case of flat transactions, and are omitted here.
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).
ST: The target savepointof the rollback
(2) +(SA(S1)|SA(S2))
(1) SB(S2)
50
The Rules for Savepoint Model
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 aborted.
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
51
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.
52
Persistent SavepointsRestart 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.
53
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.
Rules for Chained Transactions
SB(Cn): (delete(SB(Cn)),+(SA(system)|SA (Cn))),, BEGIN WORK
SA(Cn): (delete(SA(Cn)), delete(SC(Cn))),, ROLLBACK WORK
SC(Cn): (delete(SA(Cn)), delete(SC(Cn))), SB(Cn+1), COMMIT WORK
A B C
System
A C
A B C
C1
A C
A B C
C2
A C
TriggerTrigger
a) The first transaction in the chain has been started.
b) Start of the second one will be triggered by commit of the first one.
A B C
System
A C
A B C
C1
A C
A B C
C2
A C
Trigger
c) The first transaction in the chain has been committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on “system”.
54
55
Chained Transaction v.s. Savepoints
• Since the chaining step irrevocably completes a transaction, rollback is limited to the currently active transaction (Not as flexible as Savepoint)
• The COMMIT allows the application to free locks that it does not later need (Note: Persistent Savepoint does not have this property)
• 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.
A B C
System
A C
A B C
C1
A C
A B C
C2
A C
TriggerTrigger
Activetransaction
Committedtransaction
56
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.
A B C
System
A C
A B C
C1
A C
A B C
C2
A C
Trigger
commit
57
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
System
A C
A B C
C1
A C
A B C
C2
A CA B C
C1’
A C
A B C
Restart
A C
TriggerTrigger
Trigger
Trigger
Trigger
C1’ is the new instance of C1
New instanceof C1 startsover again
Restart C2Restart C2
Chained Transaction vs. Savepoints
58
Savepoints Persistent Savepoints
Chained Transaction
Rollback Any previous savepoint
Any previous savepoint
Limited to currently active
transaction
RecoveryEntire
transaction is rolled back
Reestablish most recent savepoint
Reestablish the state of most
recent commit
ConcurrencyLocks kept until
transaction commit
Locks kept until transaction
commitFree locks early
59
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 transactions, except that they lack the durability of non-nested flat transactions.
Nested Transaction - SOC
60
T1
T21
T22
T212
T211
T222
T221
T2122
T2121
T2112
T2111
Any subtransactioncan finally commit onlyif the root transaction
commits
Its commit takeseffect only if the
parent transactioncommits
61
Behavior of Nested Transactions Commit &
RollbackCommit 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.
62
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.
63
Rules for Nested Transactions
Note: The arrows labeled “wait” correspond to the precondition clauses in the rules.
SB(Tkn): +(SA(Tk)|SA (Tkn)),, BEGIN WORK
SA(Tkn): , , ROLLBACK WORK
Sc(Tkn): C(Tk) , , COMMIT WORK
A B C
T
A C
A B C
T
A C
A B C
T
A C
A B C
T1
A C
A B C
T2
A C
A B C
T11
A C
A B C
T1
A C
SystemSystem
System
TriggerTrigger
Trigger Wait
Wait
Wait
a) Root transaction T is running.
b) Subtransaction T1 has been started.
c) T1 has created subtransaction T11, and after that the root transaction starts another subtransaction, T2.
Wait
Tk is the parent of Tkn
64
Using Nested TransactionStrong 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
65
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.
66
Emulating Nested Transaction by
Savepoints
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.
Savepoint generatedat beginning of
each subtransaction
Rollback to savepoints121 has the effectof aborting Tk121
67
Limitations of the Emulation of Nesting by Savepoints (1)
– Reestablishing the state of the savepoint associated with a transaction can affect arbitrary subtransactions, rather then only the subtree of the aborting subtransaction.
• 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.
68
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.
69
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.
70
Multi-Level Transactions
A B C
T
A C
A B C
N
A C
Trigger
a) Root transaction T is running.
b) Subtransaction N has been started.
A B C
System
A C
Trigger
A B C
T
A C
A B C
System
A C
Trigger
A B C
N
A C
A B C
CN
A C
c) Subtransaction N has committed and has installed its compensation transaction, CN, that will get started if T aborts. CN must commit.
Trigger
N can commit independently of T, When it does so;
however, CN enter the scence
N can commit independently of T, When it does so;
however, CN enter the scence
CN is compensating transaction for N. It can
semantically reverse what N has done
CN is compensating transaction for N. It can
semantically reverse what N has done
Abort of T is unconditionally
linked to the commit of CN
Abort of T is unconditionally
linked to the commit of CN
71
Multi-Level Transactions vs
Nested Transactions
A B C
T
A C
A B C
System
A C
Trigger
A B C
N
A C
A B C
CN
A C
Trigger
A B C
T
A C
A B C
T1
A C
A B C
T2
A C
A B C
T11
A C
System
TriggerTrigger Wait
Wait
Wait
T2 does not havethe durability
property
Precommit: N hasthe durability
property
Nested transactionMulti-level transaction
72
Rules for Multi-Level Transactions
• Rules for subtransaction N:
SB(N): , , BEGIN WORK
SA(N): , , ROLLBACK WORK
SC(N): +(SA(T)|SB(CN)), 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.
73
Advantage & Disadvantage of Multi-
Level Transactions•Advantage: Multi-level transactions are
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.
Summary: Transaction Models
74
Flat Transaction
SavepointPersistent Savepoint
Chained Transaction
Multilevel Transaction
Nested Transaction
Support partial
rollback
Support partial
rollback
Minimize lost work in case
of system crash
Minimize lost work in case
of system crash
Improve concurrency
Improve concurrency
Support structured
programming
Support structured
programming
Improve concurrency
Improve concurrency
75
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’}
:a
Computation
76
Transaction Processing Context Example
exec sql declare cursor x select a, b, c from rel_a where d = 10 order by a ascending; open cursor x;
do { exec sql fetch next x into :a, :b, :c; /* perfrom computation */
} while (sqlcode == 0);
exec sql close cursor x;
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.
a b c d
x101010101010
379
121621
:c:b
77
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
78
COMPUTE INTERESTS
ComputeInterest (){ read (interest_rate);
for (account_no = 1; account_no <= 1,000,000; account_no++){SingleAccount(interest_rate, account_no);}
reply (“done”)};
SingleAccount (interest_rate, account_no){ BEGIN WORK
/*do account update*/COMMIT WORK;return (“OK”);
} This transaction is context-freeBecause the next account number
is passed in the input message
The surrounding program needsto keep the context just in case
something happens along the way
79
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.
80
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.
n-2
0 1 … n-1 n n+1 … i stepsize …
Accounts | |
BATCHCONTEXT
Last_account_donePROCESS Note: Isolation is
guaranteed only for the tuples the step transaction is accessing.
Database
81
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 */ }
0 1 … n-1 n n+1 … i stepsize …
Accounts | |
Last_account_doneLast_account_done Last_account_done + stepsize
Last_account_done + stepsize
82
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
83
LONG-LIVED TRANSACTIONSGeneral 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 pre-specified path or remove from the system what has been done so far.
84
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.
Added to Chained Transaction 85
SAGAS - Properties• Commit case: S1, S2, …, Si, … , Sn-1, Sn
• Rollback scenario: S1, S2, …, Sj(abort), CSj-1… , CS2, CS1
A B C
A C
A B C
A C
A B C
A C
A B C
A C
A B C
A C
A B C
A C
System S1 S2 S3
CS1 CS2
TriggerTrigger
Trigger
A backward chain of compensating transactions is established as the original chain proceeds in a forward direction.
86
COOPERATING TRANSACTIONS (1)
Cooperative transactions allow for explicit interactions among collaborating users on shared (design) objects.
Transaction A
Transaction Bcreate object X
X
do some design work
show meobject X
granted
Use object X
Give back X
Time
Preliminary,must not
be modified
B may resumecomputation
on X
87
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:
– who has access to the object
– what kind of access is requested to the object, and
– T gets informed as soon as the object is returned to its original SoC.
Summary: Transaction Models
88
Savepoints
Flattransaction
Persistentsavepoints
Chainedtransaction
Single layerof control
Can rollbackto a
savepoint
Reestablishlast savepoint
after recovery – Minimize lost work in case of system crash
Free locks early
Summary: Transaction Models
89
Savepoints
Flattransaction
Persistentsavepoints
Chainedtransaction
NestedTransaction
MultilevelTransaction
Supportsmodularization
in softwareengineering
Precommit allowsearly release
of locks
SAGAS
Chained transactionwith compensating
transactions
Summary: Transaction Models
90
Transaction1
Transaction2
May IUse “X”
CooperatingTransaction
I am donewith “X”
I know howTransaction 2
uses “X”
Recommended