Customizing the Lock Time-out

When Microsoft® SQL Server™ cannot grant a lock to a transaction on a resource because another transaction already owns a conflicting lock on that resource, the first transaction becomes blocked waiting on that resource. If this causes a deadlock, SQL Server terminates one of the participating transactions (with no time-out involved). If there is no deadlock, the transaction requesting the lock is blocked until the other transaction releases the lock. By default there is no mandatory time-out period, and no way to test whether or not a resource is locked prior to locking it, except to attempt to access the data (and potentially get blocked indefinitely).

Note The sp_who system stored procedure can be used to determine if a process is being blocked, and by whom.

The LOCK_TIMEOUT setting allows an application to set a maximum time that a statement waits on a blocked resource. When a statement has waited longer than the LOCK_TIMEOUT setting, the blocked statement is automatically canceled, and error message 1222 “Lock request time-out period exceeded” is returned to the application.

Any transaction containing the statement, however, is not rolled back or canceled by SQL Server. Therefore the application must have an error handler that can trap error message 1222. If an application does not trap the error, it can proceed unaware that an individual statement within a transaction has been canceled, and errors can occur because statements later in the transaction may depend on the statement that was never executed.

Implementing an error handler that traps error message 1222 allows an application to handle the time-out situation and take remedial action, for example, automatically resubmitting the statement that was blocked, or rolling back the entire transaction.

To determine the current LOCK_TIMEOUT setting, execute the @@LOCK_TIMEOUT function, for example:

DECLARE @Timeout int

SELECT @Timeout = @@lock_timeout

SELECT @Timeout

GO

See Also