Docstoc

ppt - lecture 10

Document Sample
ppt - lecture 10 Powered By Docstoc
					                     Computer Science
                             425
                    Distributed Systems



                            Lecture 18
                       Concurrency Control
                       Reading: Section 13.4




 2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 1
Example Transaction
  Banking transaction for a customer (ATM)
      Transfer $100 from saving to checking account;
      Transfer $200 from money-market to checking account;
      Withdraw $400 from checking account.

  Transaction:
         1. savings.deduct(100)              /* includes verification */
         2. checking.add(100)               /* depends on success of 1 */
         3. mnymkt.deduct(200)               /* includes verification */
         4. checking.add(200)               /* depends on success of 3 */
         5. checking.deduct(400) /* includes verification */
         6. dispense(400)
         7. commit


   2002 M. T. Harandi and J. Hou (modified: I. Gupta)           Lecture 18- 2
Properties of Transactions (ACID)
   Atomicity: All or nothing
   Consistency: starting in a consistent state, the transaction
    ends in a consistent state.
   Isolation: Each transaction must be performed without
    interference from other transactions, i.e., the intermediate
    effects of a transaction must not be visible to other
    transactions.
   Durability: After a transaction has completed successfully, all
    its effects are saved in permanent storage.
       Data saved in a file will survive if the server process crashes.
         “To support failure atomicity and durability, objects must be
         recoverable”
            Atomicity: store tentative object updates (for later
              undo/redo)
            Durability: store entire results of transactions (all updated
              objects) to recover from permanent server crashes.

   2002 M. T. Harandi and J. Hou (modified: I. Gupta)          Lecture 18- 3
Transaction Processing Systems

   Client

                       Trans.             Scheduler       Object
   Client              Manager                            Manager

   Client




   Client
                     Trans.                              Object
                                         Scheduler
                     Manager                             Manager
  Client

            • Transaction Workspace                                    Object
            • locking / unlocking req.       Concurrency            Creation, lock
            • Protocol management              Control                recovery,
            • Subtrans Management
                                                                     destruction


   2002 M. T. Harandi and J. Hou (modified: I. Gupta)               Lecture 18- 4
Slide from Last Class
  Transaction T1                            Transaction T2
           x= a.read()                                                     Non-
           a.write(20)                                                     serially
                                     Conflicting         y = b.read()      equivalent
                                     Ops.
                                                         b.write(30)       interleaving
                                                                           of
           b.write(x)                                                      operations
                                                         z = a.read()


           x= a.read()
           a.write(20)                                                      Serially
                                                         z = a.read()      equivalent
                                                                           interleaving
           b.write(x)
                                                                           of
                                                         y = b.read()      operations
                                                         b.write(30)
                                                                           (why?)


   2002 M. T. Harandi and J. Hou (modified: I. Gupta)                  Lecture 18- 5
Concurrent Transactions
  Transaction operations can run concurrently,
  provided “isolation” principle is not violated (same
  as interleaving ops.)
  Concurrent operations must be consistent:
     If trans.T has executed a read operation on object A, a
       concurrent trans. U must not write to A until T commits or
       aborts.
     If trans, T has executed a write operation on object A, a
       concurrent U must not read or write to A until T commits
       or aborts.
  How to implement this?
     First cut: locks




    2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 6
Example: Concurrent Transactions
   Exclusive Locks
   Transaction T1                                        Transaction T2
  OpenTransaction()
                                   Lock
  balance = b.getBalance()          B
                                                         OpenTransaction()
                                                 WAIT
                                                 on B
                                                         balance = b.getBalance()

  b.setBalance = (balance*1.1)                                     …
                                   Lock
  a.withdraw(balance* 0.1)          A
  CloseTransaction()
                                                                   …
                            UnLock              Lock
                              B                  B
                             UnLock                      b.setBalance = (balance*1.1)
                                A
                                                                                     Lock
                                                         c.withdraw(balance*0.1)      C
                                                                              UnLock
                                                         CloseTransaction()     B
                                                                               UnLock
                                                                                  C

   2002 M. T. Harandi and J. Hou (modified: I. Gupta)               Lecture 18- 7
Conflict Prevention: Locking
  Transaction managers set locks on objects they need. A concurrent
   trans. cannot access locked objects.
  Two phase locking:
      In the first (growing) phase, new locks are acquired, and in the second
       (shrinking) phase, locks are released.
      A transaction is not allowed acquire any new locks, once it has released
       any one lock.
  Strict two phase locking:
         Locking is performed when the requests to read/write are about to be
         applied.
      Unlocking is performed by the commit/abort operations of the
         transaction coordinator.
            To prevent dirty reads and premature writes, a transaction waits for
             another to commit/abort
  Use of separate read and write locks is more efficient than a single
   exclusive lock.


    2002 M. T. Harandi and J. Hou (modified: I. Gupta)          Lecture 18- 8
2P Locking: Non-exclusive locks
                 non-exclusive lock compatibility
      Lock already                        Lock requested
            set                           read       write
        none                               OK          OK
        read                               OK        WAIT
        write                             WAIT       WAIT

  A read lock is promoted to a write lock when the
   transaction needs write access to the same object.
  A read lock shared with other transactions’ read
  lock(s) cannot be promoted. Transaction waits for
  other read locks to be released.
  Cannot demote a write lock to read lock during
   transaction – violates the 2P principle
    2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 9
Locking Procedure in Strict-2P Locking
  When an operation accesses an object:
    if the object is not already locked, lock the object &
    proceed.
    if the object has a conflicting lock by another transaction,
    wait until object is unlocked.
    if the object has a non-conflicting lock by another trans.,
    share the lock & proceed.
    if the object has a lower lock by the same transaction,
          if the lock is not shared, promote the lock & proceed
          else, wait until shared locks are released, then lock &
          proceed

 When a transaction commits or aborts:
   release all locks set by the transaction


   2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 10
Example: Concurrent Transactions
   Non-exclusive Locks
   Transaction T1                                        Transaction T2

  OpenTransaction()
  balance = b.getBalance()             R-Lock
                                                   OpenTransaction()
                                         B                                              R-
                                                   balance = b.getBalance()            Lock
                                                                                        B
                                                   b.setBalance =balance*1.1
                                                         Cannot Promote lock on B, Wait

  Commit
                                                               Promote lock on B


                                                                     …
   2002 M. T. Harandi and J. Hou (modified: I. Gupta)                Lecture 18- 11
Nested Transactions


                                         T : top-level transaction
                            T1 = openSubTransaction              T2 = openSubTransaction
                                                                                      commit
  T1 :                                                    T2 :
          openSubTransaction openSubTransaction                    openSubTransaction
                                         prov. commit                                        abort
  T11 :                   T12 :                            T21 :
                                                                   openSubTransaction
           prov. commit           prov. commit                                   prov. commit
                                                                   T211 :


                                                                            prov.commit




    2002 M. T. Harandi and J. Hou (modified: I. Gupta)                     Lecture 18- 12
Locking of Nested Transactions
 1. Each transaction (i.e., root) is a single entity that
    must not access partial effects of other
    transactions
     Any lock obtained or inherited by a subtrans. is inherited by its
      parent upon provisional commit (PROV) of the subtrans.

 2. Subtrans. in a transaction with same root must
    not access partial effects of each other
     Parent subtrans cannot run concurrently with its children.
     If a parent subtrans has a lock on an object, it retains the lock
      during the time that its child subtrans is executing. That is, a
      child subtrans can obtain temporary access of its parent’s
      locks (kind of like a “lease”)
     Subtrans at the same level can run concurrently, but when
      they access the same objects, the locking scheme must
      serialize the access.


    2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 13
Lock Acquisition and Release in Nested
Transactions
 • For a subtransaction to acquire a read lock,
    – No other active subtrans can have a write lock on the object,
      and the only retainers of a write lock are its ancestors.
 • For a subtransaction to acquire a write lock,
    – No other active subtrans can have a read/write lock on that
      object, and the only retainers of read/write locks on that object
      are its ancestors.
 • When a subtransaction commits, its locks are
   inherited by its parent, allowing the parent to
   retain the locks in the same mode as the child.
 • When a subtransaction aborts, its locks are
   discarded. If the parent already retains the locks,
   it continues to do so.

    2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 14
Example: Concurrent Transactions
  What happens in the example below?
   Transaction T1                                        Transaction T2

  OpenTransaction()
  balance = b.getBalance()             R-Lock
                                                   OpenTransaction()
                                         B                                              R-
                                                   balance = b.getBalance()            Lock
                                                                                        B
                                                   b.setBalance =balance*1.1
                                                         Cannot Promote lock on B, Wait

  b.setBalance=balance*1.1

          Cannot Promote lock on B, Wait

                      …                                              …
   2002 M. T. Harandi and J. Hou (modified: I. Gupta)                Lecture 18- 15
Deadlocks
  Necessary conditions for deadlocks
       Non-sharable resources (locked objects)
       No preemption on locks
       Hold & Wait or Circular Wait

     Held by                           Held by        Wait for       Held by       Wait for
                     Wait for                                    W          ...
                 A                                A
     T                          U      T                                               V
                B                                 B

     Wait for         Held by          Wait for                  U         ...    Held by
                                                      Held by        Wait for

          Hold & Wait                                 Circular Wait




   2002 M. T. Harandi and J. Hou (modified: I. Gupta)                   Lecture 18- 16
Strategies to Fight Deadlock

  Deadlocks can be resolved by lock timeout (costly
   and open to false positives)
  Deadlock Prevention: violate one of the necessary
   conditions for deadlock (from previous slide),
   e.g., lock all objects at transaction start only
   releasing all if any acquisition fails
  Deadlock Avoidance: Have transactions declare
   max resources they will request, but allow them to
   lock at any time
  Deadlock Detection: deadlocks can be detected,
   e.g., by using a wait-for graph, & then resolved by
   aborting one of the transactions in the cycle.
   2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 17
Deadlock Resolution Using Timeout

               Transaction T                             Transaction U
      Operations              Locks             Operations         Locks

      a.deposit(100);         write lockA
                                                b.deposit(200)     write lockB
      b.withdraw(100)
                              waits forU’s      a.withdraw(200);   waits for T’s
                             lock on B                             lock on A
                          (timeout elapses)
        T’s lock on A becomes vulnerable,
                            unlockA, abort T
                                                a.withdraw(200);   write locksA
                                                                   unlock A, B



   2002 M. T. Harandi and J. Hou (modified: I. Gupta)             Lecture 18- 18
Increasing Concurrency -- Two-Version
Locking
  Two versions of an object – tentative and final (committed).
  All writes go to tentative version, all other operations go to committed
   version of the object (unless this object has been previously read before by
   this transaction itself).
  Three types of locks on an object – read, write and commit
 Rules:
  To perform a read operation, a read lock must be set on the object – always
   successful unless the object already has a commit lock.
  To perform a write operation, a write lock must be set on the object – always
   successful unless the object already has a write or commit lock.
  To commit a transaction, the coordinator attempts to convert all its write
   locks to commit locks. If this succeeds, it sets the committed version to the
   value of the tentative version (for each object).
      Transactions cannot commit writes, if other trans. that read the object are not
       complete yet.



     2002 M. T. Harandi and J. Hou (modified: I. Gupta)                 Lecture 18- 19
Lock Compatibility (read, write and commit
locks)

             For one object                               Lock to be set

                                          read                write            commit
  Lock already set         none           OK                  OK               OK
                           read           OK                  OK               wait
                           write          OK                  wait
                           commit         wait                wait




    2002 M. T. Harandi and J. Hou (modified: I. Gupta)                    Lecture 18- 20
Increasing Concurrency -- Two-Version
Locking


   Compared to read-write locking, read lock
    requests wait only for commits (and not for
    writes).
   Compared to read-write locking, this increases
    concurrency but may cause more commit
    attempts to fail
        Transactions cannot commit writes, if other trans. that read the
         object are not complete.

   Can deadlocks happen due to read-commit waits?


   2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 21
Conclusion?



  • Applications care about concurrency because it
    improves performance
  • Applications are willing to tolerate temporary
    inconsistency and deadlocks in turn
  • These inconsistencies and deadlocks need to be
    prevented or detected
  • Driven and validated by actual application
    characteristics – mostly-read applications do not
    have too many conflicting operations anyway
  • Reading for next lecture: Sections 13.5-13.7
  • HW4 due next Tuesday.

   2002 M. T. Harandi and J. Hou (modified: I. Gupta)   Lecture 18- 22

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:49
posted:5/13/2010
language:English
pages:22