Discussion :

[tulipebleu]

Bonjour,

Je ne comprends pas comment fonctionne les transactions en Oracle.
D'après les essai que j'ai fait, les transactions ne sont pas bloquants, contrairement à MySQL.

Par exemple, si j'ai 2 sessions qui font :
n=select max (id) from matable;
n=n+1;
insert into matable(id) values (n);
commit;

L'une des sessions va fonctionner, et l'autre va planter en indiquant qu'il y a un problème d'unicité sur la clef primaire.
Même en mettant le niveau d'isolation serializable, l'une des deux va planter.

N'y a t il pas un moyen de bloquer une des deux sessions au select pour qu'il attende que la 2eme session finisse son travaille ?

[Pomalaix]

Sous Oracle, le comportement par défaut de verrouillage, et d'isolation des transactions, a les caractéristiques suivantes :
- les verrous portent uniquement sur les lignes modifiées (par INSERT, UPDATE ou DELETE). Les lignes non concernées ne subissent aucun verrou.
- les SELECT ne provoquent aucun verrou
- le fait qu'une ligne soit verrouillée à cause d'une modification non encore validée n'empêche pas qu'une autre session puisse lire cette même ligne ; seulement elle verra les valeurs en vigueur avant la modification (qui sont récupérées à partir des segments d'annulation).
- une session S1 ne peut voir les effets d'une transaction effectuée par une session S2 qu'une fois que S2 aura validé sa transaction par COMMIT
- les verrous sont libérés à la fin de la transaction (COMMIT ou ROLLBACK)

Autrement dit, la seule situation qui provoque un blocage, c'est lorsque 2 sessions tentent de modifier simultanément une même ligne.

Compte tenu de tout ça, votre situation est normale :
Disons que la session S1 réussit à insérer 11 à la ligne 100 (choisie au hasard), qui devient donc verrouillée, mais le COMMIT n'a pas encore eu lieu.
S2 ne peut voir que les valeurs validées, et récupère donc 10, l'incrémente à 11, et réussit à l'insérer à la ligne 101 (choisie au hasard), qui devient donc verrouillée sans souci puisqu'il ne s'agit pas de la même ligne. Par contre à la vérification de la contrainte d'unicité, ça ne passe pas !

Dans votre cas, la bonne solution est d'utiliser une séquence, ce qui aura 2 avantages : ça sera nettement plus performant que de faire un SELECT MAX dans la table, et ça vous garantira des identifiants uniques.

[tulipebleu]

Merci, c'est très clair.