Discussion :

[dymezac]

Bonjour,


Nous utilisons Sql Server avec des pages asp.net (dans le cadre d'accès multi-utilisateur).
Nous encapsulons toutes les requêtes contenues dans une page dans une transaction READ.COMMITED.
En cas d'erreur dans une des requêtes, un rollback est effectué.

Parfois une page peut mettre plusieurs minutes à se charger.

Pendant toute la durée de la transaction (qui peut durée plusieurs minutes voire plus rarement + d'une heure), des verrous sont ils posés sur les lignes retournées par les requêtes SELECT, tout comme pour les requêtes INSERT/UPDATE ?

Si oui, je pense que les verrous sur les requêtes SELECT sont inutiles et que donc, on pourrait diminuer l'isolation de ces requêtes SELECT, via l'option snapshot ON de READCOMMITED.
(Cela augmenterait nos performances qui deviennent critiques).

J'aurai besoin de l'avis de personnes plus expertes dans ce domaine..
Mais aussi tous conseils de personnes aussi avisés que moi seront les bienvenus..

D'avance merci beaucoup..



---
P.S. : si des verrous sont posés sur les requêtes SELECT; dans le cas d'une longue transaction, si une autre transaction tente d'accèder aux même données, elle sera obligé d'attendre la fin de la première transaction, et dans ce cas, sa page ne pourra s'afficher que lorsque la première transaction sera terminée..
Or j'ai testé, et ça ne le fais pas : j'arrive à afficher rapidement une page qui accède aux mêmes données qu'une autre page que j'ai lancé avant et dont la transaction dure très longtemps (qui n'est pas terminée alors que ma deuxième page (lancée en deuxième) a pu s'afficher avant).

[rudib]

Bonjour,

En niveau d'isolation READ COMMITTED, les verrous partagés posés pour un SELECT ne sont pas maintenus durant la durée de la transaction, seulement le temps de l'instruction.

Pour quelle raison maintiens-tu une transaction durant l'exécution de la page ASP, est-ce vraiment nécessaire ? Ceci dit, une exécution de plusieurs minutes, c'est très long, il y aurait vraiment de l'amélioration de performance à affectuer.

Peux-tu nous dire pourquoi tu fais des transactions, et quelles sont, en gros les opérations effectuées ?

[dymezac]

Bonjour Rudib,

merci pour votre réponse.

Nous avons opté pour une transaction dans la durée de vie d'une page, car cela nous facilite le code (on ne gère pas les transactions car elles se gèrent toutes seules dans le page_init et le page_unload [pour faire simple])

Pendant toute la durée d'une page, on a
- des lecture/ajout/modification via des formulaires html de saisies.
- des lectures pour l'affichage de données en tableaux
- des lectures pour des parcourts d'arbres etc.. (les traitements peuvent être assez long voire très long en fonction des données que l'utilisateur demande). Sur le parcourt d'arbre on a effectivement qulques optimisation qu'on peut faire (nombre de requêtes etc..)

Pour le fait qu'on maintient la transaction sur toute la page, cela est plus sécurisant pour le programmeur (il est déjà dans une transaction, aucun risque pour l'intégrité des données).

Par contre nous réfléchissons au fait de diminuer l'isolation de la transaction en cours de transaction (j'ai vu que c'est possible dans la msdn).
Et dans ce cas, nous cherchons à savoir quelles sont les pages ou bien à quel endroit de la page on peut le faire.. A priori j'aurai dis les SELECT mais comme vous me dîtes que les verrous sur les SELECT ne sont maintenus que le temps de l'instruction, alors ce n'est pas la peine.. et donc on est déjà optimisé au mieux..

qu'en pensez vous ?

(merci)

[dymezac]

Connaissez vous le lien sur la doc MSDN qui explique comment sont traités les verrous sur les différents SELECT/INSERT/UPDATE d'un READ COMMITED ?

Pour les INSERT et UPDATE, le verrou est bien maintenu durant toute la transaction ? (enfin j'espère)

(merci)

[dymezac]

Dernière remarque :

Sachant que Read.Commited est une isolation qui a pour but de prévenir les "lectures incorrectes",

Si dans un read.Commited, les verrous ne sont maintenus que le temps de l'instruction, alors on a des possibilités de "lectures incorrectes" si une transaction concurrente modifie une donnée de l'arbre (qu'on est en train de parcourir récursivement via plusieurs SELECT séparés dans le temps) ?

ce ne sont pas des lectures incorrectes d'une seule ligne , mais une lecture incorrecte global de tout l'arbre récupéré....

J'espère ne pas trop vous embrouiller

[rudib]

Bon, le READ COMMITTED permet de garantir des lectures propres, cad qu'il prévient la lecture de lignes qui sont en train d'être modifiées, donc la lecture exactement en même temps que l'exécution d'un UPDATE.
Si l'UPDATE est dans une transaction, la lecture à partir d'une autre session devra attendre la fin de la transaction ...
Chez vous, ça peut faire pas mal de temps.

Franchement, faire systématiquement des longues transactions va tuer vos performances, pour la raison expliquée ci-dessus. Il faudrait vraiment réfléchir à l'utilité de ça ...

Pour les SELECT, tu peux les faire en READ UNCOMMITTED ( WITH (NOLOCK) ), qui n'honore pas les verrous exclusifs. En d'autres terme, permet les lectures sales.