DBMS (Deadlock, deadlock prevention, 2phase locking)
- 2. Made by Name • Solanki Gaurav P. • Nikam Rohit P. • Jena Akshay • Patel Hemanshu B.
- 3. Deadlock • In a multi-process system, deadlock is an unwanted situation that arises in a shared resource environment, where a process indefinitely waits for a resource that is held by another process. • For example, assume a set of transactions {T0, T1, T2, ..., Tn}. T0 needs a resource X to complete its task. Resource X is held by T1, and T1 is waiting for a resource Y, which is held by T2. T2 is waiting for resource Z, which is held by T0. Thus, all the processes wait for each other to release resources. In this situation, none of the processes can finish their task. This situation is known as a deadlock. • Deadlocks are not healthy for a system. In case a system is stuck in a deadlock, the transactions involved in the deadlock are either rolled back or restarted
- 4. Deadlock Prevention • To prevent any deadlock situation in the system, the DBMS aggressively inspects all the operations, where transactions are about to execute. The DBMS inspects the operations and analyzes if they can create a deadlock situation. If it finds that a deadlock situation might occur, then that transaction is never allowed to be executed. • There are deadlock prevention schemes that use timestamp ordering mechanism of transactions in order to predetermine a deadlock situation.
- 5. Wait-Die Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with a conflicting lock by another transaction, then one of the two possibilities may occur − • If TS(Ti) < TS(Tj) − that is Ti, which is requesting a conflicting lock, is older than Tj − then Ti is allowed to wait until the data-item is available. • If TS(Ti) > TS(tj) − that is Ti is younger than Tj − then Ti dies. Ti is restarted later with a random delay but with the same timestamp. • This scheme allows the older transaction to wait but kills the younger one.
- 6. Wound-Wait Scheme • In this scheme, if a transaction requests to lock a resource (data item), which is already held with conflicting lock by some another transaction, one of the two possibilities may occur − • If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is Ti wounds Tj. Tj is restarted later with a random delay but with the same timestamp. • If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource is available. • This scheme, allows the younger transaction to wait; but when an older transaction requests an item held by a younger one, the older transaction forces the younger one to abort and release the item. • In both the cases, the transaction that enters the system at a later stage is aborted.
- 7. Intent Lock • The Database Engine uses intent locks to protect placing a shared (S) lock or exclusive (X) lock on a resource lower in the lock hierarchy. Intent locks are named intent locks because they are acquired before a lock at the lower level, and therefore signal intent to place locks at a lower level. • Intent locks serve two purposes: • To prevent other transactions from modifying the higher-level resource in a way that would invalidate the lock at the lower level. • To improve the efficiency of the Database Engine in detecting lock conflicts at the higher level of granularity.
- 8. Intent Lock • For example, a shared intent lock is requested at the table level before shared (S) locks are requested on pages or rows within that table. Setting an intent lock at the table level prevents another transaction from subsequently acquiring an exclusive (X) lock on the table containing that page. Intent locks improve performance because the Database Engine examines intent locks only at the table level to determine if a transaction can safely acquire a lock on that table. This removes the requirement to examine every row or page lock on the table to determine if a transaction can lock the entire table. • Intent locks include intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX).
- 9. Isolation • Isolation, in the context of databases, specifies when and how the changes implemented in an operation become visible to other parallel operations. Transaction isolation is an important part of any transactional system. It deals with consistency and completeness of data retrieved by queries un affecting a user data by other user actions. A database acquires locks on data to maintain a high level of isolation.
- 10. 2 Phase Locking Protocol • T1 & T2 conflict in A,B,C • Both must get 3 locks to complete. • If T1 gets all 3 now, T2 must get them all before or all after. • So with respect to conflict items, the schedule will be serial.
- 11. Growing Phase • Can only LOCK items during this Phase. • May also UPGRADE • May also Read & Write once items are locked. • NO UNLOCKING in this phase • If Transaction is successful, it gets all its locks. • If Transaction is not successful, it may deadlock or fail because it cannot get a lock.
- 12. Shrinking Phase • Can only UNLOCK items during this Phase. • May also DOWNGRADE • May still Read & Write items which are still locked. • Phase begins with FIRST UNLOCK • NO LOCK after first unlock • This Phase cannot fail, but transaction may still fail because of Dirty Read • If no Dirty Read, transaction will be serial.