Spring 2004

1
A Notation for Transaction Models
Adapted from slides by J. Gray A. Reuter
2
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.

3
A Graphical Metaphor for Rules
4
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
B
A
C
T
T
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
Same as scenario 1, but
transaction will cause it
all of its event ports are
T assumes the final abort
to roll back, too.
deactivated the final state is
state.
highlighted.
5
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) -gt
• (rule modifier list), (signal list), (state
  transition)

Indicates signal that cause rule to fire.
How rule set is changed by firing.
Signal sent as result of firing.
6
Rules For Flat Transactions

• SB(T) -gt (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) -gt(delete(SB(T)),delete(SC(T))),,
  ROLLBACK_WORK
• Disables rule SB(T) and SC(T).
• SC(T) -gt (delete(SB(T)), delete(SA(T))),,
  COMMIT_WORK
• Disables rule SB(T) and SA(T).

7
Flat Transactions With Savepoints
8
Flat Transactions with Savepoints

• Allow for partial rollback
• In travel agent problem had to rollback entire
  transaction if one leg 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.

9
Flat Transactions With Savepoints
10
Flat Transactions With Savepoints

• The rule system for transactions with savepoints
• SB(Sn) -gt ,,BEGIN WORK
• SA(R) (RltSn) -gt ,SA(Sn-1), ROLLBACK WORK
• SC(Sn) -gt ,SC(Sn-1), COMMIT WORK
• SS(Sn) -gt (SA(Sn)SA(Sn 1)), SB(Sn 1),

11
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

12
Chained Transactions
13
Restart Processing
14
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.

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

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

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

18
Nested Transactions

• Visibility rule
• All changes done by a sub-transaction become
  visible to the parent transaction upon the
  sub-transactions 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.

19
Nested Transactions
20
Nested Transactions
Means that effect is conditioned on commit of
parent
21
Nested Transactions vs. Savepoints
22
Distributed Transactions
23
Multi-Level Transactions
24
Using Multi-Level Transactions
25
Using Multi-Level Transactions II
26
Using Multi-Level Transactions

• Abstraction hierarchy
• The entire system consists of a strict hierarchy
  of objects with their associated operations.
• Layered abstraction
• The objects of layer n are completely implemented
  by using operations of layer n-1.
• Discipline
• There are no shortcuts that allow layer n to
  access objects on a layer other than n-1.

27
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).