209
7.2 Verrouillage
les rendre ACID, vous devez déclarer une transaction utilisateur explicite, à l’aide
des instructions TCL (Transaction Control Language) du langage SQL :
• BEGIN TRANSACTION – débute une transaction explicite ;
• SAVE TRANSACTION – introduit un point de sauvegarde. On pourra ensuite valider ou annuler la partie de la transaction jusqu’à ce point ;
• COMMIT TRANSACTION – valide la transaction et la termine ;
• ROLLBACK TRANSACTION – annule la transaction et la termine.
Ces commandes permettent donc d’étendre les principes d’ACIDité de la transaction à plusieurs instructions DML ou DDL (en SQL Server, les instructions DDL
sont transactionnelles). Dans les faits, cela transforme une suite d’ordres SQL en un
seul ordre logique.
Validation automatique et annulation automatique
En SQL Server, le terme « transaction implicite » est utilisé pour décrire un fonctionnement
connu sous le nom de « validation automatique » (autocommit). Par défaut, une session est en
mode autocommit, c’est-à-dire qu’une instruction DML transactionnelle est automatiquement
validée ou annulée (si elle provoque une exception) après exécution. Vous pouvez changer
ce mode à l’aide de la commande SET IMPLICIT_TRANSACTIONS { ON | OFF }. En mode
IMPLICIT_TRANSACTIONS ON, toute instruction doit valider ou annuler la transaction par un
COMMIT ou un ROLLBACK. Ce mode est dangereux et en général inutile, ne l’utilisez donc pas.
De même, l’option SET XACT_ABORT { ON | OFF } permet d’annuler automatiquement une
transaction explicite lorsqu’une instruction provoque une exception. Elle est activée par
défaut. Elle influe sur la valeur de la fonction XACT_STATE() qui peut être testée, en général
dans la partie CATCH d’un bloc TRY CATCH, pour connaître l’état de la transaction. Après une
exception, si XACT_ABORT est à OFF, XACT_STATE() vaudra 1 (transaction active et validable. Si
elle est à ON, XACT_STATE() vaudra -1 (transaction active et en erreur). Lorsque XACT_STATE()
vaut -1, seul un ROLLBACK est possible.
Dans la pratique, il est rare de vouloir gérer une validation partielle de la transaction, cela peut
provoquer plus facilement de la confusion que des fonctionnalités utiles.
7.2 VERROUILLAGE
Le principe de la transaction qui nous intéresse plus particulièrement en regard des
performances, est l’isolation. Il consiste à assurer qu’une seule transaction à la fois
puisse accéder aux mêmes données. Cette isolation est réalisée à travers le mécanisme de verrouillage. Dès qu’une transaction accède à une ressource, celle-ci est
verrouillée (le moteur de stockage pose un verrou sur l’objet : la ligne, la page ou la
table), afin de la protéger des accès concurrents. Il existe plusieurs types de verrous
(ou modes de verrouillage), qui sont compatibles ou non entre eux, et plusieurs
granularités. Nous allons les passer en revue.
7.2 Verrouillage
les rendre ACID, vous devez déclarer une transaction utilisateur explicite, à l’aide
des instructions TCL (Transaction Control Language) du langage SQL :
• BEGIN TRANSACTION – débute une transaction explicite ;
• SAVE TRANSACTION – introduit un point de sauvegarde. On pourra ensuite valider ou annuler la partie de la transaction jusqu’à ce point ;
• COMMIT TRANSACTION – valide la transaction et la termine ;
• ROLLBACK TRANSACTION – annule la transaction et la termine.
Ces commandes permettent donc d’étendre les principes d’ACIDité de la transaction à plusieurs instructions DML ou DDL (en SQL Server, les instructions DDL
sont transactionnelles). Dans les faits, cela transforme une suite d’ordres SQL en un
seul ordre logique.
Validation automatique et annulation automatique
En SQL Server, le terme « transaction implicite » est utilisé pour décrire un fonctionnement
connu sous le nom de « validation automatique » (autocommit). Par défaut, une session est en
mode autocommit, c’est-à-dire qu’une instruction DML transactionnelle est automatiquement
validée ou annulée (si elle provoque une exception) après exécution. Vous pouvez changer
ce mode à l’aide de la commande SET IMPLICIT_TRANSACTIONS { ON | OFF }. En mode
IMPLICIT_TRANSACTIONS ON, toute instruction doit valider ou annuler la transaction par un
COMMIT ou un ROLLBACK. Ce mode est dangereux et en général inutile, ne l’utilisez donc pas.
De même, l’option SET XACT_ABORT { ON | OFF } permet d’annuler automatiquement une
transaction explicite lorsqu’une instruction provoque une exception. Elle est activée par
défaut. Elle influe sur la valeur de la fonction XACT_STATE() qui peut être testée, en général
dans la partie CATCH d’un bloc TRY CATCH, pour connaître l’état de la transaction. Après une
exception, si XACT_ABORT est à OFF, XACT_STATE() vaudra 1 (transaction active et validable. Si
elle est à ON, XACT_STATE() vaudra -1 (transaction active et en erreur). Lorsque XACT_STATE()
vaut -1, seul un ROLLBACK est possible.
Dans la pratique, il est rare de vouloir gérer une validation partielle de la transaction, cela peut
provoquer plus facilement de la confusion que des fonctionnalités utiles.
7.2 VERROUILLAGE
Le principe de la transaction qui nous intéresse plus particulièrement en regard des
performances, est l’isolation. Il consiste à assurer qu’une seule transaction à la fois
puisse accéder aux mêmes données. Cette isolation est réalisée à travers le mécanisme de verrouillage. Dès qu’une transaction accède à une ressource, celle-ci est
verrouillée (le moteur de stockage pose un verrou sur l’objet : la ligne, la page ou la
table), afin de la protéger des accès concurrents. Il existe plusieurs types de verrous
(ou modes de verrouillage), qui sont compatibles ou non entre eux, et plusieurs
granularités. Nous allons les passer en revue.