1 / 16

Concurrency Control Architecture for a Locking Scheduler Section 18.5

Concurrency Control Architecture for a Locking Scheduler Section 18.5. Presented By: Akash Patel ID: 113. Overview. Overview of Locking Scheduler Scheduler That Inserts Lock Actions The Lock Table Handling Locking and Unlocking Request. Principles of simple scheduler architecture.

jimbo
Download Presentation

Concurrency Control Architecture for a Locking Scheduler Section 18.5

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Concurrency ControlArchitecture for a Locking SchedulerSection 18.5 Presented By: Akash Patel ID: 113 Akash Patel

  2. Overview • Overview of Locking Scheduler • Scheduler That Inserts Lock Actions • The Lock Table • Handling Locking and Unlocking Request

  3. Principles of simple scheduler architecture • The transactions themselves do not request locks, or cannot be relied upon to do so. It is the job of the scheduler to insert lock actions into the stream of reads, writes, and other actions that access data. • Transactions do not release locks. Rather, the scheduler releases the locks when the transaction manager tells it that the transaction will commit or abort.

  4. Scheduler That Inserts Lock Actions into the transactions request stream From Transaction Read(A);Write(B) ;Commit(T) Scheduler, Part 1 Lock Table Lock(A);Read(A) Scheduler, Part 2 Read(A);Write(B)

  5. The scheduler maintains a lock table, which, although it is shown as secondary-storage data, may be partially or completely in main memory • Actions requested by a transaction are generally transmitted through the scheduler and executed on the database. • Under some circumstances a transaction is delayed, waiting for a lock, and its requests are not (yet) transmitted to the database.

  6. The two parts of the scheduler perform • Part I takes the stream of requests generated by the transactions and inserts appropriate lock actions ahead of all database-access operations, such as read, write, increment, or update. • Part II takes the sequence of lock and database-access actions passed to it by Part I, and executes each appropriately

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

  8. 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. 4. Part II when notified about the lock on some DB element, determines next transaction T’ to get lock to continue.

  9. 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 DB element A Lock information for A

  10. Lock table Entry Field • Group Mode • S means that only shared locks are held. • U means that there is one update lock and perhaps one or more shared locks. • X means there is one exclusive lock and no other locks. • Waiting • Waiting bit tells that there is at least one transaction waiting for a lock on A. • A list • A list describing all those transactions that either currently hold locks on A or are waiting for a lock on A.

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

  12. How to deal with existing Lock • 1) 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’ • 2) 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

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

  14. Handling Unlock Requests • 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.

  15. Thank you

More Related