222
Chapitre 7. Transactions et verrous
Figure 7.2 — Verrous partagés en REPEATABLE READ
Des verrous partagés (S) sont maintenus sur chaque clé de l’index clustered (KEY),
c’est-à-dire sur chaque ligne impactée dans la requête. Ces lignes ne pourront donc
pas être modifiées tant que la transaction est encore active. Nous voyons également
que des verrous d’intention partagés sont maintenus sur la page, et sur la table
(OBJECT).
Ainsi, aucune autre session ne pourra modifier ces lignes jusqu’à la fin de la transaction. À cause du verrouillage plus important, n’utilisez ce mode que lorsque vous
souhaitez, dans une transaction, utiliser le résultat de votre lecture pour des mises à
jour dans les instructions suivantes. Évitez également d’écrire du code transactionnel
qui s’exécute dans une logique inverse (par exemple SELECT puis UPDATE dans une
transaction, UPDATE puis SELECT dans une autre), car vous vous exposeriez à un risque
important de deadlock. Lorsque vous le faites dans le même ordre, SQL Server pose
des verrous de mise à jour potentielle (update, U) pour éviter le problème.
Le niveau d’isolation SERIALIZABLE représente la protection maximale contre les
erreurs transactionnelles, mais la concurrence d’accès minimale. Il protège la transaction contre les lectures fantômes, c’est-à-dire l’apparition de lignes supplémentaires lors de plusieurs lectures des mêmes données. Pour cela, SQL Server doit
verrouiller non seulement les lignes lues, mais également les « alentours » de la
ligne, pour empêcher l’insertion de données correspondant au filtre de la clause
WHERE. La nature du verrouillage dépend de la structure de la table. Si la clause WHERE
correspond à une recherche sur une colonne avec contrainte d’unicité (clé primaire,
clé unique, index unique), aucun verrou supplémentaire ne sera posé, puisqu’aucune
ligne ne pourra être ajoutée qui correspondra à la clause WHERE. Par contre, dans les
autres cas, SQL Server posera soit un verrou d’étendue de clés (key range), soit, lorsque nécessaire, un verrou sur la table entière. Les verrous d’étendues de clés ne se
rencontrent qu’en niveau SERIALIZABLE, et ne s’appliquent qu’aux index (index clus-
Chapitre 7. Transactions et verrous
Figure 7.2 — Verrous partagés en REPEATABLE READ
Des verrous partagés (S) sont maintenus sur chaque clé de l’index clustered (KEY),
c’est-à-dire sur chaque ligne impactée dans la requête. Ces lignes ne pourront donc
pas être modifiées tant que la transaction est encore active. Nous voyons également
que des verrous d’intention partagés sont maintenus sur la page, et sur la table
(OBJECT).
Ainsi, aucune autre session ne pourra modifier ces lignes jusqu’à la fin de la transaction. À cause du verrouillage plus important, n’utilisez ce mode que lorsque vous
souhaitez, dans une transaction, utiliser le résultat de votre lecture pour des mises à
jour dans les instructions suivantes. Évitez également d’écrire du code transactionnel
qui s’exécute dans une logique inverse (par exemple SELECT puis UPDATE dans une
transaction, UPDATE puis SELECT dans une autre), car vous vous exposeriez à un risque
important de deadlock. Lorsque vous le faites dans le même ordre, SQL Server pose
des verrous de mise à jour potentielle (update, U) pour éviter le problème.
Le niveau d’isolation SERIALIZABLE représente la protection maximale contre les
erreurs transactionnelles, mais la concurrence d’accès minimale. Il protège la transaction contre les lectures fantômes, c’est-à-dire l’apparition de lignes supplémentaires lors de plusieurs lectures des mêmes données. Pour cela, SQL Server doit
verrouiller non seulement les lignes lues, mais également les « alentours » de la
ligne, pour empêcher l’insertion de données correspondant au filtre de la clause
WHERE. La nature du verrouillage dépend de la structure de la table. Si la clause WHERE
correspond à une recherche sur une colonne avec contrainte d’unicité (clé primaire,
clé unique, index unique), aucun verrou supplémentaire ne sera posé, puisqu’aucune
ligne ne pourra être ajoutée qui correspondra à la clause WHERE. Par contre, dans les
autres cas, SQL Server posera soit un verrou d’étendue de clés (key range), soit, lorsque nécessaire, un verrou sur la table entière. Les verrous d’étendues de clés ne se
rencontrent qu’en niveau SERIALIZABLE, et ne s’appliquent qu’aux index (index clus-