Concurrency Control Chapter 18 Section 18.5 Presented by Khadke, Suvarna CS 257 (Section II) Id 213 1

Scheduler That Inserts Lock Actions into the transactions request stream

Scheduler That Inserts Lock Actions If transaction is delayed while waiting for a lock, Scheduler performs following actions Part I: Takes the stream of requests generated by the transaction & insert appropriate lock modes to db operations (read, write, or update) Part II: Take actions (a lock or db operation) from Part I and executes it.  Determine the transaction (T) that action belongs and status of T (delayed or not). If T is not delayed then 1. Database access action is transmitted to the database and executed 3

Scheduler That Inserts Lock Actions 2.If lock action is received by PartII, it checks the L Table whether lock can be granted or not i> Granted, the L Table is modified to include granted lock ii>Not G. then update L Table about requested lock then PartII delays transaction T 3.When a T = commits or aborts, PartI is notified by the transaction manager and releases all locks. If any transactions are waiting for locks PartI notifies PartII. 3.Part II when notified about the lock on some DB element, determines next transaction T’ to get lock to continue. 4

The Lock Table A relation that associates database elements with locking information about that element Implemented with a hash table using database elements as the hash key Size is proportional to the number of lock elements only, not to the size of the entire database 5 DB element A Lock information for A

Lock Table Entries Structure 6 Some Sort of information found in Lock Table entry 1>Group modes -S: only shared locks are held -X: one exclusive lock and no other locks - U: one update lock and one or more shared locks 2>wait : one transaction waiting for a lock on A 3>A list : T currently hold locks on A or Waiting for lock on A

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 7

Handling Lock Requests If group mode is U (update) or X (exclusive) No other lock can be granted  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) Another shared or update lock can be granted  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 8

Handling Unlock Requests 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 check entire list for new group mode S: GM(S) or nothing U: GM(S) or nothing X: nothing 9

Handling Unlock Requests 10 If the value of waiting is “yes" need to grant one or more locks using following approaches  First-Come-First-Served:  Grant the lock to the 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.