Ch 4' TransactionOriented Computing

1
Ch 4. Transaction-Oriented Computing
2
The Temporary Update Problem
Problem T2 reads the invalid temporary value.
3
The Lost Update Problem
This update is lost!
4
The Incorrect Summary Problem
210 ? 75 80 60 ? Inconsistent!
5
Outline

• Atomic Action and Flat Transactions.
• Sphere of Control.
• Notations
• Transaction Models

6
ACID Properties
A transaction can be considered a collection of
actions with the following properties

• Atomicity A transactions changes to the state
  are atomic either all happen or none happen.
• Consistency A transaction is a correct
  transformation of the state.
• Isolation Even though transactions 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.

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

• 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, but the rest is
  not.
• Read-after-Write First issues a single disk
  write, then reads the block from disk and
  compares the result with the original block.
• Problem There is no provisions to return to the
  initial state.

8
Disk Writes as Atomic Actions (2)

• Duplexed write Each block is written to two
  places on disk
• 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

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

• Unprotected Action These actions lack all of the
  ACID properties except for consistency.
• Example A single disk write.
• Protected Action They have the ACID properties.
• They do not externalize their results before they
  are completely done.
• They can roll back if anything goes wrong before
  the normal end.
• Once they have reached they normal end, what has
  happened remains.
• Real Action These actions affect the real,
  physical world in a way that is hard or
  impossible to reverse.
• Example Firing a missile.

10
Higher-Level Protected Actions (Transactions)

• Since unprotected action can be undone, they can
  be included in a higher-level operation, which as
  a whole has the ACID properties.
• Real actions need special treatment. The
  higher-level operation must make sure that they
  are executed only if all enclosing protected
  actions have reached a state in which they will
  not decide to roll back.

11
Higher-Level Protected Actions (Transactions)
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
Dont do it at all
Note The ACID properties hold for everything
executed between BEGIN_WORK and COMMIT_WORK.
12
FLAT TRANSATIONS

• A flat transaction contains an arbitrary number
  of simple actions these actions may, in term, be
  either protected, real, or even unprotected, if
  necessary.
• A flat transaction has only one layer of control.
• The transaction will either survive together with
  everything else (commit), or it will be rolled
  back with everything else (abort).
• Limitation There is no way of either committing
  or aborting parts of such transactions, or
  committing results in several steps, and so forth.

13
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), file
r CHAR(48), PRIMARY KEY (Aid)
14
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 / / /
15
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 Aid Aid / /
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)
16
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 lt 0 delta lt 0) /
check if it a debit and account overdrawn /
exec sql ROLLBACK WORK / if so dont 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.
17
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.

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

19
SPHERES OF CONTROL (1)

• Spheres of Control (SoC) are based on a hierarchy
  of abstract data types (ADTs) which execute
  atomically

20
SPHERES OF CONTROL (2)

• Spheres of Control come in two varieties
• 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.

21
Dependencies in Transaction Models (1)

• Structural dependencies These 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 the A2 appears as an atomic
  action to the outside.

22
Dependencies in Transaction Models (2)

• Dynamic dependencies This type of dependency
  arises from the use of shared data.
• Example A2 depends on A1 in the sense that A2
  can commit only if A1 does.

23
Dynamic Behavior of SoC (1)

• Beginning of scenario At time t, a problem is
  discovered in the SoC B. Data from D1 is
  determined to be the cause of the problem.

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

25
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
26
State-Transition Diagram for a Flat Transaction

• Although it is useful to describe flat
  transactions as state machines, when describing
  phenomena for which it is not possible to define
  a priori a fixed number of states, this approach
  is not appropriate.
• We will adapt the SoC model for describing
  transaction models.

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

28
Describing Transaction Models -Example

• 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 A2
  is ready to commit too.

29
Graphical Representation of Transaction Models (1)
Begin
Signal entries for the atomic action to perform a
state transition
Commit
Aborted
State indicator of the actions outcome
Eternally unique identifier of the atomic action
Commit
Aborted
Fig 4.6 A graphical notation for general
transaction models. For the graphical
representation of a transaction model, 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.
30
Graphical Representation of Transaction Models (2)
Trigger
a) Transaction T is active An abort of the
system transaction will cause it to roll back,
too.
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.
forbidden state or event
Fig 4.7 Describing flat transactions by means of
the graphical notation. A flat transaction is
nothing but an atomic action with only one
structural dependency. This dependency says that
if the system transaction aborts, the flat
transaction if 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 related to its
name. All incoming ports that cannot receive
events and all final state that cannot be assumed
are shaded.
31
Defining Transaction Models by Rules (1)
ltrule idgt ltpreconditiongt ? ltrule modifier
listgt, ltsignal listgt, ltstate transitiongt.

• The rule id specifies which signal port the arrow
  points to, and the precondition says where it
  comes from.
• Whenever a signal from a state transition
  arrives, it is not executed until the
  preconditions are fulfilled.

32
Defining Transaction Models by Rules (2)
ltrule idgt ltpreconditiongt ? ltrule modifier
listgt, ltsignal listgt, ltstate transitiongt.

• ltstate transitiongt is essentially redundant, but
  it is kept for clarity.
• ltsignal listgt 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).

33
Defining Transaction Models by Rules (3)
ltrule idgt ltpreconditiongt ? ltrule modifier
listgt, ltsignal listgt, ltstate transitiongt.

• ltrule modifiergt is used to introduce additional
  arrows as they are needed, or to delete arrows
  that have become obsolete.
• ltrule modifiergt (ltrule idgtltsignalgt)
• ltrule modifiergt - (ltrule idgtltsignalgt)
• ltrule modifiergt delete(x), x is an atomic
  action.

34
The Rules for the Flat Transaction Model
Trigger
a) Transaction T is active An abort of the
system transaction will cause it to roll back,
too.
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.

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

35
Flat Transaction with Savepoints (1)
Work covered by savepoint number 2
Work covered by savepoint number 5
36
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.

37
Graphical Representation of the Savepoint Model
Trigger
Trigger
Trigger
Trigger
Trigger
Trigger
Trigger
a) Transaction has started, establishing
savepoint 1.
Trigger
b) Next savepoint, S2, has been taken.
Trigger
c) Next savepoint, S3, has been taken.
forbidden state or event
38
Graphical Representation of the Savepoint Model
(contd)

• The basic idea is to regard the execution between
  two subsequent 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.

39
The Rules for the Savepoint Model
First Savepoint SB(S1) ? (SA(system)SA
(S1)),, BEGIN WORK SA(R) (RltS1) ? ,, ROLLBACK
WORK SC(S1) ? ,, COMMIT WORK SS(S1) ?
(SA(S1)SA (S2)), SB(S2), Intermediate
Savepoint SB(Sn) ? ,, BEGIN WORK SA(R) (RltSn)
? , SA(Sn-1), ROLLBACK WORK SC(Sn) ? , SC(Sn-1),
COMMIT WORK SS(Sn) ? (SA(Sn)SA (Sn1)),
SB(Sn1),

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

40
Persistent Savepoints (1)

• Making savepoints persistent implies that
  whenever a savepoint is taken, the state of the
  transaction must be kept in durable (persistent)
  storage.
• Restart Strategy
• The last unfinished savepoint interval is roll
  back, but
• the state as of the previous successful
  persistent savepoint is reestablished.

41
Persistent Savepoints (2)

• Problem
• Conventional programming languages do not
  understand transactions the database contents
  will return to the state as of the specified
  savepoint, but the local programming language
  variables will not.
• We will discuss the programming discipline
  imposed by the use of savepoints later.

42
CHAINED TRANSACTIONS

• Chained transactions are modeled by a sequence of
  atomic actions, executed one at a time.
• Each transaction behaves like a flat transaction.
• The commitment of one transaction and the
  beginning of the next are wrapped together into
  one atomic operation.
• The database context remains intact across the
  transaction boundaries.
• Effect The amount of work lost after a crash can
  be minimized.

43
Rules for Chained Transactions
a) The first transaction in the chain has been
started start of the second one will be
triggered by commit of the first one.
Trigger
Trigger
b) 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.
Trigger
Trigger
Note Either C1 commits, then C2 begins, or C2
fails to begin, but then C1 does not commit
either.
SB(Cn) ? (SA(system)SA (Cn)),, BEGIN
WORK SA(Cn) ? , , ROLLBACK WORK SC(Sn) ? ,SB(C
n1), COMMIT WORK
44
Chained Transaction vs. Savepoints

• Since the chaining step irrevocably completes a
  transaction, roll back is limit 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.

45
Restart Processing in Chained Transactions
From the applications 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.
Trigger
Trigger
Trigger
Trigger
Trigger
46
Nested Transactions

• A nested transaction is a tree of
  subtransactions.
• A subtransaction can either commit or rollback
  its commit will not take effect, though, unless
  the parent transaction commits.
• Any subtransaction can finally commit only if the
  root transaction commits.

Fig 4.12 Nested transactions the basic idea. A
nested transaction is a tree of transactions.
Starting at the root, each transaction can create
lower-level transactions (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.
47
The Behavior of Nested Transactions (1)

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

48
The Behavior of Nested Transactions (2)

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

49
Rules for Nested Transactions
System
System
System
Trigger
a) Root transaction T is running.
Trigger
Trigger
Wait
Wait
Wait
b) Subtransaction T1 has been started.
c) T1 has created subtransaction T11, and after
that the root transaction starts another
subtransaction, T2.
Wait
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
50
Using Nested Transaction

• There is a strong relationship between the
  concept of 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 recovered with the same granularity.

51
Transactional C

• Transactional C is a programming language
  supported by the Encina TP monitor.
• The run-time system of Transactional C supports
  the notion of nested transactions.
• Publications
• TP Monitor, TP-00-D146
• Transactional-C, Programmer Guide and reference,
  TP-00-D347
• Company Transarc Corp
• Pittsburgh, PA
• Most current database systems do not rely on
  nested transactions for their own implementation.
  This is quite surprising because nesting the
  scope of commitment and backout is common places
  even in todays SQL systems.

52
Emulating Nested Transactions by Savepoints

• Strategy If at the beginning of a subtransaction
  a savepoint is generated, then rolling back to
  that savepoint has the same effect as an abort of
  the corresponding subtransaction.

53
Limitations of the Emulation of Nesting by
Savepoints

• 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, reestablishing the state of the
  savepoint associated with a transaction can
  affect arbitrary subtransactions, rather than
  only the subtree of the aborting transaction.
• 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 since there is only one
  flat transaction.

54
Distributed Transactions

• A distributed transaction is typically a flat
  transaction that runs in a distributed
  environment.
• The decomposition into distributed transaction
  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.

55
Distributed Transactions
Distributed transactions are a restricted type of
nested transactions that are used, for example,
in distributed databases. For simplicity, only
the case of one transaction is shown. Other
subtransactions at any level are appended in
exactly the same way.
56
Multi-Level Transactions
Trigger
Trigger
Trigger
c) Subtransaction N has committed and has
installed its compensation transaction, CN, that
will get started if T aborts. CN must commit.
Trigger
a) Root transaction T is running.
Trigger
b) Subtransaction N has been started.

• 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, which means CN must not fail.

57
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 transaction CN
• SB(CN) ? (SC(restart)SB(CN)), , BEGIN WORK
• SA(CN) ? , SB(CN), ROLLBACK WORK
• SC(CN) ? delete(CN), , COMMIT WORK
• Note CN is an instance of CN. It ensures that
  the compensation continues after restart.

58
Advantage of Multi-Level Transactions
Multi-level transactions are nested transactions
with the ability to precommit the results of
subtransactions. Disadvantage The compensation
actions can be very expensive. Advantage The
scheme of layering object implementation makes
it possible to protect updates at lower layers
by isolating higher-layer objects.
59
Advantage of Multi-Level Transactions - Example
T
When this operation is done the updated page is
accessible to all transactions. However, the new
tuples are not accessible as long as T has not
finally committed.
INSERT
Conclusion Since rollback is not a frequent
operation, the advantages of having smaller
units of commitment control will outweigh the
cost of compensation by a wide margin.
60
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

61
Transaction Processing Context Example

• exec sql DECLARE CURSOR c AS
• SELECT a, b, c
• FROM rel_a
• WHERE d 10
• ORDER BY a ASCENDING
• exec sql OPEN CURSOR c
• do exec sql FETCH NEXT c INTO a, b, c
• / perform computation/
• while (SQLCODE 0)
• exec sql CLOSE CURSOR c
• Private context The cursor position is a context
  that is private to the program.
• Global context The contents of the database
  itself determine which next tuple can be
  retrieved.

62
DURABLE CONTEXT (1)

• ComputeInterest ()
• read (interest_rate)
• for (account_no 1 account_no lt 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)

63
DURABLE CONTEXT (2)

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

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

65
THE MINI BATCH (2)

• while (last_account_done lt max_account_no)
• EXEC SQL BEGIN WORK /initiate next
  mini-batch/
• EXEC SQL UPDATE accounts
• 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
• SET last_account_done
  last_account_done stepsize
• EXEC SQL COMMIT WORK
• last_account_done last_account_done
  stepsize

66
LONG-LIVED TRANSACTIONS

• Long-Lived transactions can be found in the areas
  of engineering design, office automation, etc.
• Requirements
• 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.
• Recoverable computation. There must be ways to
  temporarily stop the computation without having
  to commit the results.
• 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.

Providing adequate support for such applications
is an area of active research.
67
SAGAS Garci-Molina 87 (1)

• Saga is an extension of the notion of chained
  transactions.
• It defines a chain of transactions as a unit of
  control.
• It uses the compensation idea from multi-level
  transactions to make the entire chain atomic.

68
SAGAS Garcia-Molina 87 (2)

• A Saga has the following 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
A backward chain of compensating transaction is
established as the original chain proceeds in a
forward direction.
Trigger
A B C
A B C
CS1
CS2
A C
A C
Trigger
69
COOPERATING TRANSACTIONS (1)

• Cooperative transactions allow for explicit
  interactions among collaborating users on shared
  (design) object.

show me object X
Use object X
Give back X
do some design work
Transaction A
X
Transaction B
create object X
granted
Time
70
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 anyway, without creating
  a commit dependency on it.
• Explicit return The transaction that selectively
  releases commitment control knows who has access
  to the object and what kind of access is
  requested to the object to the object, and it
  gets informed as soon as the object is returned
  to its original SoC.

71
RESEARCH TOPICSEngineering Transaction Model

• F. Bancilhon, W. Kim and H.F. Korth, A Model of
  CAD Transaction, 11th VLDB, 1985, pp. 25-33.
• Barghout and Kaiser, Concurrency Control in
  Advanced Database Systems, ACM Computing
  Surveys. 23(3) 1991, p.269.
• H. Garcia-Molina and K. Salem, Saga, ACM
  SIGMOD, 1987, pp. 249-259.
• J. Klein and A. Reuter, Migrating Transactions,
  Workshop on the Future Trends of Distributed
  Computing System, 1988, pp. 512-520.
• Y. Leu, A.K. Elmargarmrd and N-Boudriga,
  Specification of Transactions for Advanced
  Database Applications, 1990, Purdue University,
  CSD-TR-1030.
• A. Reuter, Contracts A means for Extending
  Control Beyond Transaction Boundaries, 3rd Intl
  Workshop on High Performance Transaction System.