locking
play

LOCKING CS 2550 / Spring 2006 Principles of Database Systems 10 - PowerPoint PPT Presentation

LOCKING CS 2550 / Spring 2006 Principles of Database Systems 10 Locking Alexandros Labrinidis University of Pittsburgh 2 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Centralized DBMS Locking T 1 T 2 T n


  1. LOCKING CS 2550 / Spring 2006 Principles of Database Systems 10 – Locking Alexandros Labrinidis University of Pittsburgh 2 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Centralized DBMS Locking T 1 T 2 T n  Centralized DBMS Architecture {Start, Read(x), Write(x), Commit, Abort} Transaction Manager  Schedulers {Start, Read(x), Write(x), Commit, Abort} Actions of Scheduler: 1. Execution Scheduler  Aggressive 2. Reject  Conservative 3. Delay {Start, Read(x), Write(x), Commit, Abort} Data Manager Recovering Manager  Lock-based concurrency control {Flush(x), Fetch(x), Fix(x), Unfix(x), Write(x) } Cache Manager  Deadlocks Database Buffer Log Buffer  Detection Stable Database DiskRead(x,a,b) Temporary Log  Prevention DiskWrite(x,a,b) and Catalog Support: Transaction UNDO Global UNDO | Partial REDO Archive Log Support: Global REDO 3 4 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 1

  2. Types of schedulers Aggressive Vs Conservative Schedulers  Almost all types of schedulers have both an aggressive  A scheduler upon receiving an operation may and a conservative version.  Execute the operation immediately, perhaps remembering the dependencies.  Delay the operation.  Extreme case of conservative scheduler is a serial  Reject the operation. scheduler.  A scheduler is aggressive if it avoids delaying operations thereby running the risk of rejecting them later.  Preferable if conflicts are rare.  A scheduler is conservative if it deliberately delays operations thereby avoiding their (possible) subsequent rejection.  Attempts to anticipate future behavior of transactions.  Preferable if conflicts are likely. 5 6 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Lock Based Concurrency Control Lock Based Concurrency Control  Locks conflict if they are associated with conflicting  Locking is the most common synchronization operations, i.e., operations that will form some mechanism. dependency.  A lock is associated with each data item in the rl j (x) wl j (x) database. rl i (x) No Yes  A lock on x indicates that a transaction is performing wl i (x) Yes Yes an operation on x .  If transactions Ti and Tj request conflicting locks on  Lock types data item x and Ti locks x first, then Tj should wait until  rl i (x) : x is read lock by T i ( shared lock) Ti unlocks x .  wl i (x) : x is write lock by T i ( exclusive lock) – ru i (x) : remove the read lock from x set by T i – wu i (x) : remove the write lock from x set by T i 7 8 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 2

  3. Why Simple Mutual Exclusion Why Simple Mutual Exclusion Does Not Suffice Does Not Suffice Consider the following schedule based on mutual exclusion  T 1 T 2 Comments  Assume rl(x) granted Database = { x, y } b=r(x) Initially: x = 0, y = 1 ru(x) released rl(y) granted Transactions a=r(y) T 1 : a = r(y); w(x, a) /* x ← y */ ru(y) released T 2 : b = r(x); w(y, b) /* y ← x */ wl(x) granted w(x,a) Final database wu(x) released state: x = 1, y = 0. commit This history is not wl(y) granted SR! Why not? w(y,b) wu(y) released commit 9 10 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Basic Two Phase Locking (2PL) Basic Two Phase Locking (2PL) A scheduler following the 2PL protocol has two phases: Example:   H 1 : rl(x); a = r(x); wl(y); w(y, a); ru(x); wu(y); A Growing phase   H 2 :rl(x); a = r(x); ru(x); wl(y); w(y, a); wu(y); Whenever it receives an operation p i (x) the scheduler obtains a p-  lock on x ( pl i (x) ) before executing p on the data. A Shrinking phase   Theorem : Every 2PL history H is serializable.  Once a scheduler has released a lock for a transaction,it cannot  request any additional locks on any data item for this transaction. Note: Eswaran, Gray, Lorie, Traiger - ``The Notions of  Consistency and Predicate Locks in a Database System'', CACM , vol. 19, no. 11 Nov. 1976, pp. 624-633 11 12 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 3

  4. Two Phase Locking: Serializability Issues Related To Locking  Lock point  Deadlock  The point in the schedule where the transaction Two or more transactions are blocked indefinitely has obtained its final lock because each holds locks on data items upon which the  = the end of the growing phase in 2PL others are trying to perform operations, i.e., obtain locks.  Livelock  Serializable ordering: Livelock occurs when a transaction is aborted and restarted repeatedly (Cyclic Restart), e.g., because its priority is too low.  Order transactions according to their lock points Differs from deadlock in that it allows a transaction to execute but not to completion.  2PL does not guarantee freedom from deadlocks  Starvation Starvation occurs when a transaction is never allowed to run, e.g.,because there is always a transaction with a higher priority. 13 14 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Conservative (Static) 2PL Conservative (Static) 2PL  A transaction T declares in advance all data items that it But: might read or write.  Transactions are blocked for conflicts that may never arise in an actual execution.  A transaction is executed when the scheduler obtains all the locks on the declared data items.  Starvation is possible.  No deadlocks since there are no lock conflicts while transactions are executing.  Transactions may need to lock more data items than  Low message passing overhead between transactions really need to access. and the scheduler.  Requires pre-processing. 15 16 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 4

  5. Aggressive (Dynamic) 2PL Aggressive (Dynamic) 2PL  A transaction requests locks just before it operates on a But: data item.  More message passing between transactions and  If a transaction holds a read lock on an item x and later on scheduler. it decides to update x, it can (try to) convert its read lock on x to a write lock. (This is called lock conversion .)  Transactions may deadlock.  A transaction cannot convert a write lock to a read lock. This is equivalent to releasing the write lock and obtaining  Cannot reorder operations later and hence may have a read lock. to abort them.  Transactions only lock the data items that they really need. 17 18 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Strict 2PL  It is a form of aggressive (dynamic) 2PL  transactions request locks just before they operate on a data item.  The growing phase ends at commit time .  no locks can be released until commit or abort time.  no overwriting of dirty data.  no overwriting of data read by active transactions.  no reading of dirty data.  Is it easy to implement strict 2PL? 19 20 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 5

  6. Deadlocks Deadlocks  Examples:  A deadlock occurs when two or more transactions are blocked indefinitely.  each holds locks on data items on which the other transaction(s) attempt to place a conflicting lock.  Necessary conditions for deadlock situations.  mutual exclusion  hold and wait  no preemption  circular wait.  Example II involves lock conversion  The scheduler restarts any transaction aborted due to deadlock. 21 22 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Deadlock Detection: Timeout Deadlock Detection: Timeout  The scheduler checks periodically if a transaction has been  Fine tuning of the timeout period: blocked for too long. Long timeout : fewer mistakes by the scheduler, but a  In such a case, the scheduler assumes that the transaction is deadlock may exist unnoticed for long deadlocked and it aborts the transaction. periods causing long delays.  This method may incorrectly diagnose a situation to be a Short timeout : quick deadlock detection, but more mistakes deadlock. are possible thus aborting transactions not  The scheduler may make a mistake and abort a transaction that involved in a deadlock. waits for another transaction that is taking a long time to finish.  The correctness of the schedule is not affected if the  Advantage: very simple algorithm. scheduler makes a wrong guess.  Tandem used deadlock detection based on timeout. 23 24 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 Alexandros Labrinidis, Univ. of Pittsburgh CS 2550 / Spring 2006 6

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend