A deadlock is an example of a catch-22 situation. A deadlock occurs when two or more transactions have a lock on a separate object. Each wants to acquire a lock on the other transaction's object. When this happens, the first transaction is waiting for the second transaction to release the lock, but the second transaction will not let go until the lock on the first transaction's object is freed. At such a point, both transactions are at an impasse and can't proceed with their work. A deadlock can occur when several long-running transactions execute concurrently in the same database.
SQL Server automatically avoids the most common types of deadlocks. If a deadlock does occur, SQL Server detects and automatically resolves it by rolling back the first transaction that will break the deadlock for all other pending transactions, if there are more than two. In this way, the remaining transaction(s) obtains the needed lock and is free to continue. The application with the aborted transaction resubmits the transaction at a later time, when it is likely to proceed without incident.
SQL Server also automatically prevents lock starvation. Lock starvation occurs when read transactions can monopolize a table or page, forcing a write transaction to wait indefinitely. SQL Server prevents lock starvation by coordinating table and page accesses for read and write transactions in an intelligent way, based on a first-come, first-served strategy.