236
Chapitre 7. Transactions et verrous
SQL Server fonctionne de la même façon : un deadlock se produit lorsqu’une
transaction attend la libération d’un verrou de la part d’une autre transaction, qui
elle-même attend la libération d’un verrou de la première transaction. La situation
est sans solution, et SQL Server le détecte à l’aide d’un thread de surveillance dédié,
qui lance une recherche à travers toutes les sessions ouvertes 1 . Lorsqu’il rencontre
une situation de deadlock, il choisit une victime (la transaction qui a effectué le
moins de modification de données), et annule (ROLLBACK) cette transaction. Une
erreur 1205 est envoyée à la session choisie comme victime, avec ce message :
Transaction (Process ID XX) was deadlocked on lock resources with
another process and has been chosen as the deadlock victim.
Rerun the transaction.
Dans des applications de bases de données correctement implémentées, un deadlock devrait être une situation rare. Elle ne peut se produire que dans le cas d’une
transaction explicite, dans un contexte particulier. Illustrons-le par un exemple de
code :
-- dans la session 1
BEGIN TRAN
UPDATE HumanResources.Employee SET MaritalStatus = 'S'
WHERE Gender = 'F'
UPDATE c SET Title = 'Miss'
FROM Person.Contact c
JOIN HumanResources.Employee e WITH (READUNCOMMITTED)
ON c.ContactID = e.ContactID
WHERE e.Gender = 'F'
COMMIT TRAN
-- dans la session 2
BEGIN TRAN
UPDATE c SET Suffix = 'Mrs'
FROM Person.Contact c
JOIN HumanResources.Employee e WITH (READUNCOMMITTED)
ON c.ContactID = e.ContactID
WHERE e.Gender = 'F'
UPDATE HumanResources.Employee SET MaritalStatus = 'M'
WHERE Gender = 'F'
COMMIT TRAN
Comme vous le voyez, les deux transactions effectuent des opérations similaires
dans un ordre inversé. C’est la porte ouverte à un deadlock. Il suffit que les transac1. Pour ne pas consommer trop de ressources, le thread de surveillance se lance toutes les cinq
secondes, et augmente automatiquement sa fréquence si des situations de deadlock sont détectées.
Plus d’informations dans les BOL, entrée « Detecting and Ending Deadlocks ».
Chapitre 7. Transactions et verrous
SQL Server fonctionne de la même façon : un deadlock se produit lorsqu’une
transaction attend la libération d’un verrou de la part d’une autre transaction, qui
elle-même attend la libération d’un verrou de la première transaction. La situation
est sans solution, et SQL Server le détecte à l’aide d’un thread de surveillance dédié,
qui lance une recherche à travers toutes les sessions ouvertes 1 . Lorsqu’il rencontre
une situation de deadlock, il choisit une victime (la transaction qui a effectué le
moins de modification de données), et annule (ROLLBACK) cette transaction. Une
erreur 1205 est envoyée à la session choisie comme victime, avec ce message :
Transaction (Process ID XX) was deadlocked on lock resources with
another process and has been chosen as the deadlock victim.
Rerun the transaction.
Dans des applications de bases de données correctement implémentées, un deadlock devrait être une situation rare. Elle ne peut se produire que dans le cas d’une
transaction explicite, dans un contexte particulier. Illustrons-le par un exemple de
code :
-- dans la session 1
BEGIN TRAN
UPDATE HumanResources.Employee SET MaritalStatus = 'S'
WHERE Gender = 'F'
UPDATE c SET Title = 'Miss'
FROM Person.Contact c
JOIN HumanResources.Employee e WITH (READUNCOMMITTED)
ON c.ContactID = e.ContactID
WHERE e.Gender = 'F'
COMMIT TRAN
-- dans la session 2
BEGIN TRAN
UPDATE c SET Suffix = 'Mrs'
FROM Person.Contact c
JOIN HumanResources.Employee e WITH (READUNCOMMITTED)
ON c.ContactID = e.ContactID
WHERE e.Gender = 'F'
UPDATE HumanResources.Employee SET MaritalStatus = 'M'
WHERE Gender = 'F'
COMMIT TRAN
Comme vous le voyez, les deux transactions effectuent des opérations similaires
dans un ordre inversé. C’est la porte ouverte à un deadlock. Il suffit que les transac1. Pour ne pas consommer trop de ressources, le thread de surveillance se lance toutes les cinq
secondes, et augmente automatiquement sa fréquence si des situations de deadlock sont détectées.
Plus d’informations dans les BOL, entrée « Detecting and Ending Deadlocks ».