Chapter 18.5 An Architecture For A Locking Scheduler Steve Ikeoka ID: 113 CS 257 – Spring 2008

Locking Scheduler A scheduler that inserts lock requests into the transactions’ request stream Scheduler, Part I Scheduler, Part II Lock Table From Transactions READ(A); WRITE(B); COMMIT(T); … LOCK(A); READ(A); … READ(A); WRITE(B); …

Locking Scheduler (cont’d) Part I takes the stream of requests from the transactions and inserts lock actions ahead of all database-access operations Must select an appropriate lock mode Part II executes the sequence of actions passed to it by Part I Determines whether to delay the transaction T because a lock has not been granted If so, then add the action to the list of actions that must eventually be performed for transaction T

Locking Scheduler (cont’d) If the action is a database access, it is transmitted to the database and executed If the action is a lock request, examine the lock table to see if the lock can be granted If so, modify the lock table to include the lock just granted If not, make an entry in the lock table to indicate that the lock has been requested. Then delay further actions for transaction T, until the lock is granted

Locking Scheduler (cont’d) When a transaction T commits or aborts Part I releases all locks held by T If any transactions are waiting for any of these locks, Part I notifies Part II When Part II is notified that a lock on some database element X is available It determines the next transaction or transactions that can now be given a lock on X Those transactions are allowed to execute their delayed actions until they either complete or reach another lock request that cannot be granted

Example T 1 : r 1 (A); r 1 (B); w 1 (B); T 2 : r 2 (A); r 2 (B); T 1 T 2 r 1 (A);sl 1 (A); r 1 (A); r 2 (A); sl 2 (A); r 2 (A); r 2 (B); sl 2 (B); r 2 (B); r 1 (B);ul 1 (B); r 1 (B); w 1 (B);xl 1 (B) Denied u 2 (A); u 2 (B); Order of Operations:xl 1 (B); w 1 (B); Left->Right, Top->Bottomu 1 (A); u 1 (B); Scheduler May need exclusive lock later T2 is holding a lock on B Can now obtain X lock on B

The Lock Table A relation that associates database elements with locking information Size is proportional to the number of lock elements only, not to the size of the entire database DB element A Lock information for A

Lock Table Entry Components Group Mode is a summary of the most stringent conditions that a transaction requesting a new lock on A faces S – only shared locks are held U – one U lock and perhaps S locks X – one exclusive lock and no other locks Waiting bit tells that there is at least one transaction waiting for a lock on A

Lock Table Entry Components (cont’d) List describing all transactions either holding or waiting for a lock on A. Each entry has: The name of the transaction The mode of this lock Whether transaction is holding or waiting Pointer linking entries together Point linking all entries for a particular transaction (Tnext). Used when a transaction commits or aborts to find all the locks that must be released

Structure of Lock Table Entries A Element Info Group Mode: U Waiting: yes List: T1T1 Sno T2T2 U T3T3 Xyes TranModeWait?TnextNext T 1 has S lock and T 2 has U lock so Group Mode is U T 3 is waiting to obtain an X lock so Waiting is ‘yes’

Handling Lock Requests Suppose transaction T requests a lock on A If there is no lock table entry for A, then there are no locks on A, so create the entry and grant the lock request If the lock table entry for A exists, use the group mode to guide the decision about the lock request

Handling Lock Requests (cont’d) If group mode is U (update) or X (exclusive) Deny the lock request by T Place an entry on the list saying T requests a lock And Wait? = ‘yes’ If group mode is S (shared) Grant request for an S or U lock Create entry for T on the list with Wait? = ‘no’ Change group mode to U if the new lock is an update lock

Handling Unlocks Now suppose transaction T unlocks A Delete T’s entry on the list for A If T’s lock is not the same as the group mode, no need to change group mode Otherwise if T’s lock is: X, then there are no other locks U or S, then determine if there are S locks remaining.

Handling Unlocks (cont’d) If the value of Waiting is ‘yes’ Need to grant one or more lock requests Several different approaches: First-Come-First-Served: Grant longest waiting request. No starvation (waiting forever for lock) Priority to Shared Locks: Grant all S locks waiting, then one U lock. Grant X lock if no others waiting Priority to Upgrading: If there is a U lock waiting to upgrade to an X lock, grant that first.