Discussion :

[mezzo_998]

Bonjour,

J'ai un problème dans l'utilisation des transactions.
J'ai deux applications différentes qui lisent une même table.

La première application lie et modifie certaines lignes. Il y a une série d'instructions qui sont inclues dans une transaction.


Je voudrais que la deuxième application puisse accéder (lecture et modification) aux lignes non modifiées par la première ou attende la fin de la transaction de la 1ère application pour accéder aux lignes verrouillées.

Mon problème et que la transaction de la 1ère application me bloque systématiquement toute la table et non pas seulement les lignes concernées.


Comment faire pour que la transaction bloque des enregistrements et non l'intégralité de la table ?

Merci d'avance pour votre aide.

[Ch0n]

Je suis pas sure mais je crois que les transaction bloque les table dans leur intégralite, après avoir avec d'autre pour savoir si cela est possible...

[mezzo_998]

Si j'ai bien compris, je crois qu'il y a en fait 2 types de verrous (lecture et modification). Je crois que seuls les enregistrements modifiés ont un verrou de modification (les verrous sont posés sur des enregistrements et/ou des pages ou la table entière de manière automatique). Par contre il me semble que tous les enregistrements de la table ont un verrou en lecture : c'est ce qui me gêne et je ne comprends pas pourquoi

[kagemaru]

Sql server gère automatiquement le verrouillage. Lorsqu'il juge qu'il y a trop de lignes verrouillées par une màj, il augmente l'étendu d'un verrou jusqu'à verrouiller la table si nécessaire. Plus sql server pose des verrous, plus la consommation de ressource est élevée. C'est pour cela qu'il convertit souvent certains verrous en version plus générale pour bloquer une table au lieu de 100000 lignes de cette même table.

Dans ton cas, tu peux obliger sql server à conserver un verrouillage par ligne en ajout un hint aux commandes update et delete :

Code :

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

UPDATE table WITH (ROWLOCK) set col=X where ....

A ce moment là, sql server ne verrouillle que les lignes. Attention, car si ta requete verrouille bcp de lignes, tu peux rapidement te retrouver avec une machine à genoux, le nb de verrous à gérer étant très important.

pour comprendre un peu mieux les mécanismes de promotion de verrous :
http://technet.microsoft.com/fr-fr/l.../ms184286.aspx

[mezzo_998]

Je viens d'essayer mais ça ne marche pas. Je dois avoir un paramètre incorrect.
Voici le code de mes requêtes :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
--Requête 1
set transaction isolation level READ COMMITTED
begin transaction
 
update  t_ligne_prelevement with (ROWLOCK) set id_etat_ligne_prelevement = 3 where id_article = 0
 
--Requête 2
set transaction isolation level READ COMMITTED
begin transaction
 
select * from T_LIGNE_PRELEVEMENT where id_article <>0

Malheureusement la seconde requête "se bloque" en attendant que je commit ou rollback la 1ère transaction.

Une idée de ce qui ne va pas.

[kagemaru]

as-tu un index sur la colonne id_article ?

[mezzo_998]

Non je n'ai pas d'index sur la colonne id_article. Par contre, il y a une clé étrangère dessus vers la colonne id_article de la table T_ARTICLE (dans laquelle id_article est la PK).

[kagemaru]

la table à indexer est t_ligne_prelevement, en créant un index sur id_article

[mezzo_998]

J'ai essayé d'ajouter un index sur la colonne id_article de la table T_LIGNE_PRELEVEMENT mais ça ne marche pas non plus.

[kagemaru]

j'ai plusieurs cas où ça marche dans cette config (rowlock + index), je suis désolé, il faudrait voir avec un sp_lock pour voir les verrous en détail mais ça risque d'être pénible.

[s.cardinaux]

Il me semble que SQLServer, lorsqu'on lui demande de locker beaucoup de ligne, (avec with rowlock) pose de lui même à la place un ou plusieurs verrou de page, voir il locke la table entièrement.

De plus, dans ta requête de sélection tu verrouilles l'intégralité de la table (et oui il faut aussi spécifier les verrous dans les select) du coup ton select attend la libération des verrous de ton update même si les lignes demandés ne coïncident pas.

Le mieux étant à mon avis d'ajouter des WITH(NOLOCK) systèmatiquement dans les select lorsqu'elle ne sont pas utilisés pour garantir la cohérence des données.

Il n'y a pas moyen à ma connaissance de récupérer le contenu d'un table sauf les lignes lockés par SQLServer (et je ne pense pas cela souhaitable).