208
Chapitre 7. Transactions et verrous
qui met à jour près de 20 000 lignes. Que se passe-t-il si une erreur se produit au
milieu de cette modification, ou si, en même temps, une autre session change le nom
d’un contact ? Du point de vue du SGBDR, ce sont des incohérences. Pour assurer
que cela ne se produise pas, toute modification (insertion, suppression, mise à jour)
de données est obligatoirement protégée par un mécanisme transactionnel qui
garantit, à travers quatre critères, la consistance de cette modification. Ces critères
sont nommés « l’acidité » de la transaction, par leur acronyme (ACID). Une transaction doit être :
• Atomique – Une transaction est atomique, parce qu’elle représente une seule
unité de modification, même si la mise à jour porte sur plusieurs milliers de
lignes, ou plusieurs tables. Cela signifie qu’une telle modification sera totalement validée, ou totalement annulée. La base de données ne restera jamais
dans un état intermédiaire, où une partie seulement des modifications est
enregistrée.
• Cohérente – Elle est cohérente, parce qu’elle ne peut violer les contraintes de
la base de données, ou laisser la base dans un état intermédiaire. Si dans une
mise à jour de cent lignes, une ligne viole une contrainte d’intégrité référentielle (une clé étrangère), la transaction sera totalement annulée. La base
passe d’un état cohérent avant la transaction, à un état cohérent après validation.
• Isolée – La transaction s’exécute dans un contexte d’isolation vis-à-vis des
autres transactions. Les lignes touchées par une modification sont protégées
contre un accès par une autre transaction, que ce soit en lecture (selon le
niveau d’isolation, nous le verrons), ou surtout, en écriture.
• Durable – Lorsque la transaction est validée, elle est durable, c’est-à-dire que
les modifications sont définitivement inscrites dans la base de données, sauf
défaillance matérielle du disque, bien entendu.
Pour illustrer l’utilité de cette acidité, imaginez-vous une partie de billard. Lorsque c’est votre tour de jouer, vous restez à la table tant que vous placez une bille dans
une poche. Quand vous avez fini, vos points sont enregistrés, on ne peut revenir en
arrière. Votre tour est donc atomique et durable. Vous ne pouvez violer les règles du
jeu, sinon votre action est nulle, c’est donc consistant. Et, le plus important, personne ne peut jouer en même temps que vous : lorsque c’est votre tour, personne
d’autre ne touche les billes sur la table, sinon, le jeu ne signifie plus rien.
La durabilité et l’atomicité sont possibles grâce au journal de transactions, qui
permet de rejouer ou d’annuler une transaction, quelle que soit sa durée. L’isolation,
qui est l’attribut qui garantit la cohérence des modifications tout en diminuant la
concurrence, est gérée à travers le mécanisme de verrouillage.
Toute instruction DML de modification de données (INSERT, UPDATE, DELETE,
MERGE) est encapsulée dans une transaction. Un seul UPDATE par exemple, quel que
soit le nombre de lignes qu’il affecte, est donc ACID. Le SELECT ne génère aucune
transaction. Pour enrôler plusieurs instructions dans une seule transaction, et donc
Chapitre 7. Transactions et verrous
qui met à jour près de 20 000 lignes. Que se passe-t-il si une erreur se produit au
milieu de cette modification, ou si, en même temps, une autre session change le nom
d’un contact ? Du point de vue du SGBDR, ce sont des incohérences. Pour assurer
que cela ne se produise pas, toute modification (insertion, suppression, mise à jour)
de données est obligatoirement protégée par un mécanisme transactionnel qui
garantit, à travers quatre critères, la consistance de cette modification. Ces critères
sont nommés « l’acidité » de la transaction, par leur acronyme (ACID). Une transaction doit être :
• Atomique – Une transaction est atomique, parce qu’elle représente une seule
unité de modification, même si la mise à jour porte sur plusieurs milliers de
lignes, ou plusieurs tables. Cela signifie qu’une telle modification sera totalement validée, ou totalement annulée. La base de données ne restera jamais
dans un état intermédiaire, où une partie seulement des modifications est
enregistrée.
• Cohérente – Elle est cohérente, parce qu’elle ne peut violer les contraintes de
la base de données, ou laisser la base dans un état intermédiaire. Si dans une
mise à jour de cent lignes, une ligne viole une contrainte d’intégrité référentielle (une clé étrangère), la transaction sera totalement annulée. La base
passe d’un état cohérent avant la transaction, à un état cohérent après validation.
• Isolée – La transaction s’exécute dans un contexte d’isolation vis-à-vis des
autres transactions. Les lignes touchées par une modification sont protégées
contre un accès par une autre transaction, que ce soit en lecture (selon le
niveau d’isolation, nous le verrons), ou surtout, en écriture.
• Durable – Lorsque la transaction est validée, elle est durable, c’est-à-dire que
les modifications sont définitivement inscrites dans la base de données, sauf
défaillance matérielle du disque, bien entendu.
Pour illustrer l’utilité de cette acidité, imaginez-vous une partie de billard. Lorsque c’est votre tour de jouer, vous restez à la table tant que vous placez une bille dans
une poche. Quand vous avez fini, vos points sont enregistrés, on ne peut revenir en
arrière. Votre tour est donc atomique et durable. Vous ne pouvez violer les règles du
jeu, sinon votre action est nulle, c’est donc consistant. Et, le plus important, personne ne peut jouer en même temps que vous : lorsque c’est votre tour, personne
d’autre ne touche les billes sur la table, sinon, le jeu ne signifie plus rien.
La durabilité et l’atomicité sont possibles grâce au journal de transactions, qui
permet de rejouer ou d’annuler une transaction, quelle que soit sa durée. L’isolation,
qui est l’attribut qui garantit la cohérence des modifications tout en diminuant la
concurrence, est gérée à travers le mécanisme de verrouillage.
Toute instruction DML de modification de données (INSERT, UPDATE, DELETE,
MERGE) est encapsulée dans une transaction. Un seul UPDATE par exemple, quel que
soit le nombre de lignes qu’il affecte, est donc ACID. Le SELECT ne génère aucune
transaction. Pour enrôler plusieurs instructions dans une seule transaction, et donc