Home/ Questions/Q 8809229
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T02:49:07+00:00

In a SQL Server 2005 with default configuration, read_committed isolation level and read_committed snapshot

  • 0

In a SQL Server 2005 with default configuration, read_committed isolation level and read_committed snapshot off. Could a query abort because of a deadlock? If so, why?

What about if I increase the isolation level to Repeatable reads?

According to msdn documents a situation like this is possible with any level of isolation :

Transaction T_1 acquires a share lock on row 1.
Transaction T_2 acquires a share lock on row 2.
Transaction T_1 now requests an exclusive lock on row 2 ( because it wants to change it), and is blocked until transaction T_2 finishes and releases the share lock it has on row 2.
Transaction T_2 now requests an exclusive lock on row 1 ( because it wants to change it), and is blocked until transaction T_1 finishes and releases the share lock it has on row 1.
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    SQL Server uses several types of locks – if it needs to write data (e.g. insert new data or update existing rows), it will need to use an exclusive lock – always, in any isolation level.

    With the fact that you have exclusive locks in play, there’s always a chance of a deadlock – process A holds an exclusive lock on resource A and needs exclusive access to resource B, while another process B has the exclusive lock on resource B and wants access to resource A.

    This can happen in any isolation level (even with READ UNCOMMITTED, SQL Server will take out exclusive locks for writing data!) and my point is: the more restrictive an isolation level is, the longer these locks tend to stick around, thus the higher the chance becomes that a deadlock can occur.

    If you haven’t already – you should be all means read, re-read, and re-re-read the following articles until you get a good understanding of the SQL Server locking mechanisms:

    • 0