Discussion :

[Pol63]

Bonjour,


Un bout de la question dépend peut etre d'ADO.net, mais ca me semblait plus logique de venir là, vous me direz si je me trompe ...

Depuis un programme .net nous ouvrons une connexion, exécutons un select, lisons 3 lignes, faisons pause

puis on ouvre une autre connexion, on démarre une transaction, on delete la table, puis on dépause la 1ère connexion

et là moi je trouve ca surprenant mais on arrive encore à lire des lignes ... et je ne pense pas avoir activé de snapshot quelquepart ...

le delete a pu se finir, nous laissons la connexion ouverte sans commit ou rollback, pensant vérrouiller la table
et le select est fait après un SET ISOLATION LEVEL READ COMMITTED

si on tente d'exécuter la requete après le delete on a bien un timeout à cause du verrouillage

l'origine de ce test c'est qu'on sait que le positionnement à la ligne suivante peut planter s'il y verrouillage par une autre connexion, ca nous est déjà arrivé à priori et on veut voir ce qui se passe en détail ...
avec ado.net sur le select c'est executereader pour exécuter puis un while .read pour lire chaque ligne

Merci de m'éclairer sur ce sujet

[rudib]

Je ne sais pas si j'ai tout bien compris à ta situation, mais si tu fais un SELECT, que tu récupères un dataset, ou autre, et que tu le parcours dans ton code .NET, le jeu de résultat est manipulé en local et n'est plus requêté, donc tu peux toujours accéder à tes lignes, puisqu'il s'agit d'un jeu de résultats local.

[Pol63]

pas un dataset non, je lis les lignes avec un sqldatareader, en forward only

[rudib]

Hum, avec un curseur côté serveur ou client ? Je ne suis pas très au clair avec ça. Selon John Papa c'est du connecté.
http://msdn.microsoft.com/en-us/magazine/cc188717.aspx

qu'est-ce que tu vois dans le profiler pendant que tu boucles dans la sqldatareader ? des sp_cursorfetch ? http://msdn.microsoft.com/fr-fr/library/ff848736.aspx

[Pol63]

je viens de regarder dans profiler, j'ai coché tout ce qu'il y avait dans cursor et rien n'apparait
je vais souvent des traces en cochant stmtstarting/completed /rpc /batch et je n'ai jamais vu de sp_cursorfetch au milieu du reste

le datareader c'est bien du connecté en théorie, par contre je ne pense pas qu'il rapatrie les données avant qu'on commence à lire les données, car l'executereader peut prendre 5ms alors que la boucle sur datareader.read qui positionne sur la prochaine ligne peut prendre des secondes
et donc je pense bien que c'est un curseur

dans le meilleur des cas je vois bien un snapshot côté serveur, mais je ne vois aucun paramètre qui irait en ce sens

de plus comme dit précédemment nous avons déjà eut une erreur d'exécution sur le .read, ce qui nous a fait pensé qu'il y avait un verrou par une autre connexion, bienqu'on pensait aussi qu'sql serveur ayant exécuté la requete select il aurait mis des intentions de verrous partagé en lecture

[rudib]

Si, il est clair que quand tu exécutes ton reader, il exécute le SELECT. Ensuite, il peut fetcher un curseur coté serveur en utilisant le sp_cursorfetch. Le langage SQL est ensembliste, il n'y a pas d'appel individuel à des lignes d'une table pendant que tu tournes une boucle du côté du client. Donc si tu ne vois pas de fetch au niveau du serveur, il devrait utiliser un curseur côté client.

Par contre ce que tu dis sur la latence sur le MoveNext de ta boucle est troublant. Si tu le fais en pas à pas et que tu regardes ce qui se passe sur le serveur avec le profiler, qu'est-ce qui se passe en terme de requête SQL sur le MoveNext ?

[Pol63]

Par contre ce que tu dis sur la latence sur le MoveNext de ta boucle est troublant. Si tu le fais en pas à pas et que tu regardes ce qui se passe sur le serveur avec le profiler, qu'est-ce qui se passe en terme de requête SQL sur le MoveNext ?

j'aurais tendance à dire rien du tout vu que je n'ai rien vu passé tout à l'heure ni avant

après je ne sais pas s'il y a vraiment une latence sur le next, mais il y a aussi une latence sur le getvalues qui récupère les valeurs de la ligne