ECE569 Lecture 07-2.1 Spring 2004 A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter

ECE569 Lecture 07-2.1 Spring 2004

A Notation for Transaction Models

active

committed aborted

ROLLBACK WORK

COMMIT WORKterminate

terminate

NULL

BEGIN WORK

Adapted from slides by J. Gray & A. Reuter


Dependencies Between Transactions

Structural dependencies Reflect the hierarchical organization of the system into abstract

data types of increasing complexity. reflects the invocation hierarchy of the system.

Dynamic dependencies Arises from the use of shared data. Can envelop any number of otherwise unrelated atomic

actions.


A Graphical Metaphor for Rules

A B C

A C

signal entries for the atomic action to perform a state transition

abort commitbegin

state indicators of the action's outcome

aborted committed

Teternally unique identifier of the atomic action


Describing Flat Transactions

A B C

A C

system

A B C

A C

T

A B C

A C

system

A B C

A C

T

A B C

A C

system

A B C

A C

T

a) Transaction T is active; an abort of the system transaction will cause it to roll back, too.

trigger

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 state.


The Rule Language

For each atomic action define a set of rules that define its effect. One rule for each state transition the action can perform

The structure of an arbitrary rule is as follows:(rule identifier):(preconditions) ->

(rule modifier list), (signal list), (state transition)

How rule setis changed byfiring.

Signal sent asresult of firing.

Indicates signalthat cause ruleto fire.


Rules For Flat Transactions

SB(T) : -> +(SA(system)|SA(T)),, BEGIN_WORK Rule is fired when signal ‘Begin Work’ is received. Adds rule that causes ‘Abort Work’ signal to be sent when

SA(system) rule is fired. SA(T) : ->(delete(SB(T)),delete(SC(T))),,

ROLLBACK_WORK Disables rule SB(T) and SC(T).

SC(T) : -> (delete(SB(T)), delete(SA(T))),, COMMIT_WORK Disables rule SB(T) and SA(T).


Flat Transactions With Savepoints

BEGIN WORK:1

SAVE WORK:2

SAVE WORK:3

SAVE WORK:4

ROLLBACK WORK(2)

action

action

action

action

action

action

action

SAVE WORK:5

SAVE WORK:6

SAVE WORK:7

ROLLBACK WORK(7)

action

action

action

action

action

action

action

SAVE WORK:8

action

action

action

COMMIT WORK


Flat Transactions with Savepoints

Allow for partial rollback In travel agent problem had to rollback entire transaction if

one lag could not be reserved. Instead do the following

Attempt to reserve San Francisco to Frankfurt if successful establish savepoint 2

Attempt to reserve Frankfurt to Milan - if successful establish savepoint 3.

If not rollback to savepoint 2 and try for Frankfurt to Rome - if successful establish savepoint 4.



A B C

A C

A B C

A C

system

S1

trigger

A B C

A C

A B C

A C

system

S1

trigger

A B C

A CS2

triggera) Transaction has started,

establishing savepoint 1

b) Next savepoint S2 has been taken

trigger

A B C

A C

A B C

A C

system

S1

trigger

A B C

A CS2

trigger

trigger

A B C

A CS3

triggertrigger

c) Next savepoint S3 has been taken



The rule system for transactions with savepointsSB(Sn) : -> ,,BEGIN WORK

SA(R) : (R<Sn) -> ,SA(Sn-1), ROLLBACK WORK

SC(Sn) : -> ,SC(Sn-1), COMMIT WORK

SS(Sn) : -> +(SA(Sn)|SA(Sn + 1)), SB(Sn + 1),


Chained Transaction

Sequence of transactions Upon commitment of one transaction, next one begins Not possible to rollback beyond current transaction When one transaction ends all resources not needed in

future are freed, e.g., give up unnecessary locks close unneeded cursors


Chained Transactions

A B C

A C

A B C

A C

system C1

trigger

A B C

A CC2

trigger

a) The first transaction in the chain has been started; start of the second one will be triggered by commit of the first one.

A B C

A C

A B C

A C

system C1

trigger

A B C

A CC2

trigger

A B C

A CC3

b) The first transaction in the chain has committed; the second one got started as part of commit of C1. Now the second one is structurally dependent on "system".


Restart Processing

A B C

A C

A B C

A C

system C1

trigger

A B C

A C

C2

trigger

A B C

A C

C1'

A B C

A C

restart

trigger

trigger

trigger

trigger


Chained Transactions vs. Savepoints

Workflow structure Both allow a substructure to be imposed on a long-running

application program.

Commit versus savepoint 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.


Chained Transactions vs. Savepoints

Work lost Savepoints allow more flexible state restoration. Savepoints are not persistent - enclosing transaction is

aborted. After failure entire transaction must be redone.

With chained transactions, the state of the most recent commit is restored.

Less work is lost in that situation.


Nested Transactions

Definition summarized from [Moss81] 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 sub-transaction can either commit or rollback; its commit will not take effect, though, unless the parent transaction commits.

The rollback of a transaction anywhere in the tree causes all its sub-transaction to roll back.


Nested Transactions

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.


Nested Transactions

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.


Nested Transactions

BEGIN WORK . . . invoke sub-TA . . . . invoke sub-TA . . . . . invoke sub-TA . . . COMMIT WORK

BEGIN WORK invoke sub-TA invoke sub-TA . COMMIT WORK

BEGIN WORK . . .COMMIT WORK

BEGIN WORK . invoke sub-TA . COMMIT WORK

BEGIN WORK . ROLLBACK WORK

BEGIN WORK invoke sub-TA COMMIT WORK

BEGIN WORK . .COMMIT WORK

Top-level transaction Sub-transactions Sub-transactionsTk

Tk1

Tk2

Tk3

Tk11

Tk12

Tk31

BEGIN WORK . COMMIT WORK

Tk121

Sub-transactions


Nested Transactions

A B C

A CT

trigger

A B C

A CT

trigger

A B C

A CT1

trigger

A B C

A CT

trigger

A B C

A CT2T1

A B C

A C

a) Root transaction T is running

b) Sub-transaction T1 has been started

triggerwait

system system system

T11A B C

A C

trigger

wait

wait

wait

c) T1 has created sub-transaction T11, and after that the root transaction starts another sub-transaction T2

Means that effectis conditioned on commit of parent


Nested Transactions vs. Savepoints

Tk

Tk1

TK2

Tk3

Tk11

Tk12

Tk121

Tk31

time

establish savepoint

s11

s121

s2

s31

s3

s1

s12

commit


Distributed Transactions

A B C

A C

T

trigger

A B C

A C

T

trigger

A B C

A C

T1

trigger

a) Root transaction T is running

b) Remote sub-transaction T1 has been started

system system

trigger

trigger trigger


Multi-Level Transactions

A B C

A C

A B C

A C

system

T

trigger

A B C

A C

A B C

A C

system

T

trigger

A B C

A CN

trigger

A B C

A C

A B C

A C

system

T

trigger

A B C

A CCNN

A B C

A C

a) Top-level transaction T is running

b) Sub-transaction N has been started

c) Sub-transaction N has committed and has installed its compensation transaction CN that will get started if T aborts. CN must commit.

trigger


Using Multi-Level Transactions

T

SELECT ... INSERT ... UPDATE ... SELECT ...

Insert tuple Insert B-tree entry

Insert address table entry

Update page Locate position Insert entry

Split page


Using Multi-Level Transactions II

Original sequence of actions

Sequence of counter-actions

Find free page; let the number be P Update free space information

Locate free space information for page P Update free space information

Read page P Update the page header Insert tuple t

Read page P Remove tuple t Update page header

Grab free database key K

Release database key K

Insert K into page header of page P into entry pertaining to t

Remove K from t's page header entry in page P

Read page containing entry for database key value K Insert pointer to P into table entry

Read page containing entry for database key value K Remove pointer from table entry Remember page number P

Invocation : Insert_Tuple (t,ret_code)

Invocation : Remove_Tuple(K,ret_code)

t t


Using Multi-Level Transactions

Abstraction hierarchyThe entire system consists of a strict hierarchy of objects with

their associated operations.

Layered abstractionThe objects of layer n are completely implemented by using

operations of layer n-1.

DisciplineThere are no shortcuts that allow layer n to access objects on

a layer other than n-1.


Multi-Level Transactions

Advantages Subtransaction can commit immediately

Objects become available to other transactions sooner Better peformance

Disadvantages Requires a well-structured and well-understood structure Requires the definition of a compensating transaction for

each subtransaction that commits early Recovery by compensating transactions often takes longer

than physical recovery (copying back the before image).

Documents

ECE569 Lecture 07-2.1 Spring 2004 A Notation for Transaction Models Adapted from slides by J. Gray & A. Reuter