Discussion :

[lacombefr]

Bonjour,


Avec les collègues nous avons constaté quelque chose d'étonnant.

Dans une transaction en mode Read Commited (par défaut sous SQL Server), nous avons fait ce test :

Dans un processus (une "nouvelle requête") sous Sql Server Management, nous avons mis un verrou sur une ligne comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SET TRANSACTION ISOLATION LEVEL READ COMMITED
BEGIN TRANSACTION
update t_exemple where id=1234;
WAITFOR DELAY '00:00:20'
COMMIT TRANSACTION

La ligne de t_exemple dont l'id est 1234 est verrouillé pendant 20 secondes.

Dans ce laps de temps, nous avons verifié que la ligne était bien verrouillé, avec une nouvelle requête dans Sql Server Management (2eme processus sur Sql Server) avec cette procédure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from t_exemple where id=1234;

Effectivement, la ligne était bien verrouillé car elle ne nous a été rendu qu'après la fin de la première requête.

Ensuite on a fait la même chose mais nous avons remplacé la deuxième requête par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from t_exemple

Sans préciser que nous voulions l'id 1234.

Eh bien, le résultat comprenant l'id 1234 nous a été retourné avant la fin de la première requête.. Il semble donc qu'il n'y avait pas de verrou sur la ligne dont l'id est 1234.

Auriez vous une explication à cela ?


D'avance merci beaucoup

[diva-bibi]

Est que vous avez repeté plusieurs fois l'expérience ?

[lacombefr]

bonjour,

oui bien sur. Je vous invite à faire la même expérience vous même pour le vérifier (ou non) ..

[lacombefr]

rebonjour,

Je n'ai toujours pas résolu ce problème..

Je suis à l'affut de toutes explications..

[SQLpro]

Vous êtes totalement à côté de la plaque... en effet :

La ligne de t_exemple dont l'id est 1234 est verrouillé pendant 20 secondes.

Non ! En mode READ COMMITTED vous avez l'assurance que le SELECT lira des données validées. Une fois le SELECT effectué il peut se passer tout ce que l'on veut. Autrement dit une fois les données sont lues les verrous sont immédiatement libérés.
Ce comportement est donc parfaitement logique et attendu...

Si vous aviez lu mon livre sur SQL vous auriez vu quels sont les différents niveaux d'isolation de la norme SQL et ce que cela implique.
Néanmoins, rien ne vous empêche de lire l'article que j'ai écrit au sujet des différents niveaux d'isolation normatifs et SQL Server, avec ses différentes démonstrations : http://www.sqlspot.com/Gerer-l-isola...nsactions.html

Si vous utilisez le niveau REPEATABLE READ alors les verrous sont maintenus, mais cela n'empêche pas les anomalies transactionnelles venant de tuples fantômes...

A +

[lacombefr]

Bonjour SqlPro,


Si vous saviez le nombre de fois ou vous m'avez aidé (sous différents pseudo)..

Je vais commander votre livre dans la semaine..

Merci