-
Première expérience : l'utilisateur 1
effectue des mises-à-jour, tandis que
l'utilisateur 2 ne fait que des sélections.
Que constate-t-on ?
SEL1, SEL2, MAJker1, SEL2, MAJpas, SEL2, ROL1, SEL2.
- idem, mais avec des commit.
SEL1, SEL2, MAJker1, SEL2, COM1, SEL2, MAJker1, SEl2, COM1, SEL2.
- Maintenant les deux utilisateurs effectuent des MAJ simultanées.
SEL1, SEL2, MAJker1, MAJpas2, SEl1, SEL2, MAJfog1, MAJfog2, SEL1, COM1, COM2.
Un bloquage est apparu. Pourquoi ?
- Idem, avec un ordre des opérations qui diffère d'un utilisateur
à l'autre.
SEL1, SEL2, MAJker1, MAJpas2, SEl1, SEL2, MAJpas1, MAJker2 ROL1 ROL2.
Que constate-t-on ?
- (trèfle)En fait, ORACLE pratique une verrouilage à deux phases
assez libéral, qui ne garantit pas la sérialisabilité :
aucun verrrou n'est placé sur une ligne lors d'une lecture.
L'utilisateur peut verrouiller explicitement en
ajoutant la clause FOR UPDATE. Exemple :
SELECT * FROM client FOR UPDATE;
Chaque ligne sélectionnée est alors verrouillée.
Refaites les expériences précédentes avec un verrouillage
explicite des lignes que vous voulez modifier.
- (trèfle)Expérimentez les exécutions écédentes en spécifiant
le mode suivant :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE