Docstoc

Ch 4. Transaction-Oriented Computing

Document Sample
Ch 4. Transaction-Oriented Computing Powered By Docstoc
					Transaction-Oriented Computing

           COP 6730




                                 1
The Temporary Update Problem
 T1 (Transfer)    T2 (Deposit)   X Y     M   N
                                 80 60   4   5
 Read(X);
 X := X - N;
 Write(X);                       75 60   4   5
                  Read(X);                       Problem: T2
 T1 fails                                        reads the invalid
 Recover(X);                     80 60   4   5   “temporary”
                  X := X + M;
                                                 value.
                  Write(X);      79 60   4   5
 Read(X);
 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
                Read (X);
This update     X = X - N;
is lost!                         Read (X);
                                 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;
                  Read(W);
                  Sum = Sum + W;   70   70 80 60   5
Read(X);                                               Transactions can
X = X - N;
Write(X);                          70   70 75 60   5
                                                       be processed
                  Read(X);                             concurrently for
                  Sum = Sum + X;
                  Read(Y);
                                                       efficiency.
                  Sum = Sum + Y;   205 70 75 60    5   However, they
Read(Y);
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.,
  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!
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.
        Problem: There is no provisions to return to the initial state.
                                                                      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
                             Deadlock

          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
      inadequate.)
  –   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)
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.


                                                     24
 SPHERES OF CONTROL


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




                                        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
    (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).
                                                             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
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.
                                                      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 ()
{ read (interest_rate);
   for (account_no = 1; account_no <= 1,000,000; account_no++)
         {SingleAccount(interest_rate, account_no);}
   reply (“done”)
};
                                                    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:
   – 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.                                              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

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:2/27/2012
language:
pages:86