Locking and Deadlocks PRESENTED BY JANARDAN PANDEY VENKATESH

Locking and Deadlocks PRESENTED BY: JANARDAN PANDEY VENKATESH NADAR

Why locking is needed? ? �Locking is a mechanism used by the Microsoft SQL Server Database Engine to synchronize access by multiple users to the same piece of data at the same time. �Before a transaction acquires a dependency on the current state of a piece of data, such as by reading or modifying the data, it must protect itself from the effects of another transaction modifying the same data.

�The transaction does this by requesting a lock on the piece of data. �The lock mode defines the level of dependency the transaction has on the data. No transaction can be granted a lock that would conflict with the mode of a lock already granted on that data to another transaction. �All locks held by a transaction are released when the transaction completes (either commits or rolls back).

Types of Locks shared exclusive update Intent Schema Bulk update Key Range SHARED • Used for read operations that do not change or update data, such as a SELECT statement. EXCLUSIVE • Used for data-modification operations, such as INSERT, UPDATE, or DELETE. Ensures that multiple updates cannot be made to the same resource at the same time. Update • Used on resources that can be updated. Prevents a common form of deadlock that occurs when multiple sessions are reading, locking, and potentially updating resources later.

INTENT SCHEMA BULK UPDATE • Used to establish a lock hierarchy. The types of intent locks are: intent shared (IS), intent exclusive (IX), and shared with intent exclusive (SIX). • Used when an operation dependent on the schema of a table is executing. • The types of schema locks are: schema modification (Sch-M) and schema stability (Sch-S). • Used when bulk copying data into a table and the TABLOCK hint is specified.

KEY RANGE • Ensures that other transactions cannot insert rows that would qualify for the queries of the serializable transaction if the queries were run again.

DEADLOCKS � A deadlock occurs when there is a cyclic dependency between two or more threads for some set of resources. � Deadlock is a condition that can occur on any system with multiple threads, not just on a relational database management system. � A thread in a multi-threaded system may acquire one or more resources (for example, locks).

� If the resource being acquired is currently owned by another thread, the first thread may have to wait for the owning thread to release the target resource. � The waiting thread is said to have a dependency on the owning thread for that particular resource.

� If the owning thread wants to acquire another resource that is currently owned by the waiting thread, the situation becomes a deadlock: both threads cannot release the resources they own until their transactions are committed or rolled back, and their transactions cannot be committed or rolled back because they are waiting on resources the other owns.

Minimizing deadlocks… �Access objects in the same order. �Avoid user interaction in transactions. �Keep transactions short and in one batch. �Use a lower isolation level.

Deadlock Detection Deadlock detection is performed by a lock monitor thread that periodically initiates a search through all of the tasks in an instance of the Database Engine. The following points describe the search process: � The default interval is 5 seconds. � If the lock monitor thread finds deadlocks, the deadlock detection interval will drop from 5 seconds to as low as 100 milliseconds depending on the frequency of deadlocks. � If the lock monitor thread stops finding deadlocks, the Database Engine increases the intervals between searches to 5 seconds.

Thank You