1. 18.5 An Architecture for a Locking Scheduler
General Principles: The transaction themselves do not request locks, or cannot be relied upon to do so. Transactions do not release locks. Rather, the scheduler releases the locks when the transaction manager tells it that the transaction will commit or abort.

2. 18.5.1 A Scheduler That Inserts Lock Requests into the transactions request stream

3. Contd
If a transaction is delayed, waiting for a lock, and its requests are not transmitted to database. Scheduler performs the following actions:
1. Part I: Takes the stream of requests generated by the transaction & insert appropriate lock actions ahead of all database-access operations (read, write, or update).
The database access actions are transmitted to Part II.
2. Part II: Take the sequence of lock and database-access actions passed to it by Part I, and executes each appropriately.

4. Contd
If access request is received by Part II, it determines whether the issuing transaction (T) is already delayed.
If transaction (T) is delayed, the action itself delayed and added to a lit of actions that must be performed for transaction (T).

5. 18.5.1 Contd If transaction (T) is not delayed, then
(a) If the action is a database access, it is transmitted to the database and executed.
(b) If a lock action is received by Part II, it examines the lock table to see if the lock can be granted.
i. If so, the lock table is modified to include the lock just granted.
ii. If not, an entry must be made in the lock table to indicate that the lock has been requested.

6. Contd
3. When a transaction (T) commits or aborts, Part I is notified by the transaction manager, and releases all locks held by (T). If any transactions are waiting for any of these locks, Part I notifies Part II.
4. 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

7. The Lock Table
The lock table is a relation associates database elements with locking information about that element.
Implemented with a hash table using (addresses of) database elements as the hash key
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

8. Contd
The graph shows the sort of information find in a lock-table entry.
Also, the entry shown for a database element A is a tuple with the following:
1. the group mode is a summary of most stringent conditions a transaction requesting a new lock on A faces.

9. Structure of lock-table entries
Element Info
Group mode: U
Waiting: yes
List: A
Tran Mode Wait? Tnext Next
T S no
T U no
T X yes

10. 18.5.2 Contd S – means only shared locks are held
U – means there is one update lock and one or more shared locks
X – means there is one exclusive lock and no other locks
2. The waiting bit tells there is at least one transaction waiting for a lock on A

11. Contd
3. A list describes all those transactions that either hold locks on A or are waiting for a lock on A. List entry might include:
(a) the name if transaction holding or waiting for a lock.
(b) the mode of this lock
(c) Whether the transaction is holding or waiting for the lock

12. 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

13. Handling Lock Requests--Contd
If group mode is U (update) or X (exclusive),
then no other lock can be granted
The lock request by T is denied
An entry will be placed on the list saying T requests a lock
Wait? = ‘yes’
If group mode is S (shared), then another shared or update lock can be granted
Entry for T on the list would have Wait? = ‘no’
Change group mode to U if the new lock is an update lock

14. Handling Unlocks 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, examine the entire list to find new group mode

15. Handling Unlocks--Contd
If the value of waiting is “yes”, we need to grant one or more locks using following approaches:
1. First-Come-First-Served:
Grant the lock request that has been waiting the longest.
No starvation (waiting forever for lock)
2. Priority to Shared Locks:
Grant all the S locks waiting, then grant one U lock.
Grant X lock if no others waiting
3. Priority to Upgrading:
If there is a U lock waiting to upgrade to an X lock, grant that first.