Bonjour à tous ,
Après avoir lu tout ce qui concerne les verrous sur SQL et voulant me
débarrasser de ma propre gestion des verrous voici mon problème :
Utilisateur « A » voulant accéder pour modif à champ de l’enregistrement «
ID=1 » de la table « T », Utilisateur « B » voulant accéder pour modif àu
même champ de l’enregistrement « ID=1 » de la table « T », Utilisateur « C »
voulant accéder pour visu à enregistrement « ID=1 » de la table « T » soit
encore le même.
Avant je changeais la valeur d’un bit de l’enregistrement ce qui me
permettais de bloquer B et de prevenir C de l’enregistrement était encours de
modif et « A » avait tous le temps nécessaire de faire sa modif. (Ce genre de
cas arrive très souvent chez nous.).
Voici ma question : peut-on passer par les verrous d’ SQLServer et les
transactions ? (Par contre je pense que je vais être dans le cas de
transaction côté client plus complexe à gérer que du côté serveur mais ?)
Exemple :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
SET LOCK_TIMEOUT 3000
BEGIN TRANSACTION
SELECT * FROM progs WITH (XLOCK) WHERE prog = 'PEGASE'
Ce qui me bloque le ou les enregistrements de la table progs qui répondent
aux WHERE. Pour les autres utilisateurs au bout de 3 secondes message
d’erreur 1222. Pour eviter de la bloquer trop longtemps.
Une fois le modifie et l’Udate fait je fais mon COMMIT de transaction.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter [MVP]
je ne suis pas sur d'avoir compris ton besoin, mais quand un enreg (ou un index) est locké pour modif (exclusif) , il le reste jusqu'à la fin de la transaction. Par défaut, l'isolation est "read commited", ce qui veut dire qu'une lecture est impossible en cas de lock exclusif (modif enreg ou index), et donc avec un lock timeout, on sort en erreur 1222, si on ne veut pas etre bloqué en lecture, on lit avec l'option NOLOCK ou on passe en isolation est "read uncommited".
J'espère que ça peu t'aider
br
"Philip" wrote in message news:
Bonjour à tous , Après avoir lu tout ce qui concerne les verrous sur SQL et voulant me débarrasser de ma propre gestion des verrous voici mon problème : Utilisateur « A » voulant accéder pour modif à champ de l'enregistrement « ID=1 » de la table « T », Utilisateur « B » voulant accéder pour modif àu même champ de l'enregistrement « ID=1 » de la table « T », Utilisateur «
C »
voulant accéder pour visu à enregistrement « ID=1 » de la table « T » soit encore le même.
Avant je changeais la valeur d'un bit de l'enregistrement ce qui me permettais de bloquer B et de prevenir C de l'enregistrement était encours
de
modif et « A » avait tous le temps nécessaire de faire sa modif. (Ce genre
de
cas arrive très souvent chez nous.).
Voici ma question : peut-on passer par les verrous d' SQLServer et les transactions ? (Par contre je pense que je vais être dans le cas de transaction côté client plus complexe à gérer que du côté serveur mais ?)
Exemple :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE SET LOCK_TIMEOUT 3000 BEGIN TRANSACTION SELECT * FROM progs WITH (XLOCK) WHERE prog = 'PEGASE'
Ce qui me bloque le ou les enregistrements de la table progs qui répondent aux WHERE. Pour les autres utilisateurs au bout de 3 secondes message d'erreur 1222. Pour eviter de la bloquer trop longtemps. Une fois le modifie et l'Udate fait je fais mon COMMIT de transaction.
Salutations. Philip
je ne suis pas sur d'avoir compris ton besoin, mais quand un enreg (ou un
index) est locké pour modif (exclusif) , il le reste jusqu'à la fin de la
transaction.
Par défaut, l'isolation est "read commited", ce qui veut dire qu'une lecture
est impossible en cas de lock exclusif (modif enreg ou index), et donc avec
un lock timeout, on sort en erreur 1222, si on ne veut pas etre bloqué en
lecture, on lit avec l'option NOLOCK ou on passe en isolation est "read
uncommited".
J'espère que ça peu t'aider
br
"Philip" <Philip@discussions.microsoft.com> wrote in message
news:ADAADAAC-65B9-44C0-A0AD-5007499F9CA2@microsoft.com...
Bonjour à tous ,
Après avoir lu tout ce qui concerne les verrous sur SQL et voulant me
débarrasser de ma propre gestion des verrous voici mon problème :
Utilisateur « A » voulant accéder pour modif à champ de l'enregistrement «
ID=1 » de la table « T », Utilisateur « B » voulant accéder pour modif àu
même champ de l'enregistrement « ID=1 » de la table « T », Utilisateur «
C »
voulant accéder pour visu à enregistrement « ID=1 » de la table « T » soit
encore le même.
Avant je changeais la valeur d'un bit de l'enregistrement ce qui me
permettais de bloquer B et de prevenir C de l'enregistrement était encours
de
modif et « A » avait tous le temps nécessaire de faire sa modif. (Ce genre
de
cas arrive très souvent chez nous.).
Voici ma question : peut-on passer par les verrous d' SQLServer et les
transactions ? (Par contre je pense que je vais être dans le cas de
transaction côté client plus complexe à gérer que du côté serveur mais ?)
Exemple :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
SET LOCK_TIMEOUT 3000
BEGIN TRANSACTION
SELECT * FROM progs WITH (XLOCK) WHERE prog = 'PEGASE'
Ce qui me bloque le ou les enregistrements de la table progs qui répondent
aux WHERE. Pour les autres utilisateurs au bout de 3 secondes message
d'erreur 1222. Pour eviter de la bloquer trop longtemps.
Une fois le modifie et l'Udate fait je fais mon COMMIT de transaction.
je ne suis pas sur d'avoir compris ton besoin, mais quand un enreg (ou un index) est locké pour modif (exclusif) , il le reste jusqu'à la fin de la transaction. Par défaut, l'isolation est "read commited", ce qui veut dire qu'une lecture est impossible en cas de lock exclusif (modif enreg ou index), et donc avec un lock timeout, on sort en erreur 1222, si on ne veut pas etre bloqué en lecture, on lit avec l'option NOLOCK ou on passe en isolation est "read uncommited".
J'espère que ça peu t'aider
br
"Philip" wrote in message news:
Bonjour à tous , Après avoir lu tout ce qui concerne les verrous sur SQL et voulant me débarrasser de ma propre gestion des verrous voici mon problème : Utilisateur « A » voulant accéder pour modif à champ de l'enregistrement « ID=1 » de la table « T », Utilisateur « B » voulant accéder pour modif àu même champ de l'enregistrement « ID=1 » de la table « T », Utilisateur «
C »
voulant accéder pour visu à enregistrement « ID=1 » de la table « T » soit encore le même.
Avant je changeais la valeur d'un bit de l'enregistrement ce qui me permettais de bloquer B et de prevenir C de l'enregistrement était encours
de
modif et « A » avait tous le temps nécessaire de faire sa modif. (Ce genre
de
cas arrive très souvent chez nous.).
Voici ma question : peut-on passer par les verrous d' SQLServer et les transactions ? (Par contre je pense que je vais être dans le cas de transaction côté client plus complexe à gérer que du côté serveur mais ?)
Exemple :
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE SET LOCK_TIMEOUT 3000 BEGIN TRANSACTION SELECT * FROM progs WITH (XLOCK) WHERE prog = 'PEGASE'
Ce qui me bloque le ou les enregistrements de la table progs qui répondent aux WHERE. Pour les autres utilisateurs au bout de 3 secondes message d'erreur 1222. Pour eviter de la bloquer trop longtemps. Une fois le modifie et l'Udate fait je fais mon COMMIT de transaction.
Salutations. Philip
Philip
Re, Merci pour ta réponse, mais mon problème n'est pas tout à fait là: C'est plutôt comment gérer des verrouillages pessimistes. Par exemple : j’ai une fiche client que « A » est un train de manipuler en vue de faire une modification, je ne veux pas que « B » puisse y accéder.
à T1 « A » fait un select pour obtenir la fiche à T2 « A » manipule la fiche par le PGM de gestion la fiche doit restée bloquer en ecriture et voir en lecture, « B » veux accéder à la fiche refuser parce que « A » manipule la fiche. à T3 « A » fait son update, « B » est de nouveau autorisé à faire son select.
C’est ce « refuser » que j’essaie de trouver. La début de solution que j’avais mise ne fonctionne pas ! Salutations
Re,
Merci pour ta réponse, mais mon problème n'est pas tout à fait là: C'est
plutôt comment gérer des verrouillages pessimistes. Par exemple : j’ai une
fiche client que « A » est un train de manipuler en vue de faire une
modification, je ne veux pas que « B » puisse y accéder.
à T1 « A » fait un select pour obtenir la fiche
à T2 « A » manipule la fiche par le PGM de gestion la fiche doit restée
bloquer en ecriture et voir en lecture,
« B » veux accéder à la fiche refuser parce que « A » manipule la fiche.
à T3 « A » fait son update, « B » est de nouveau autorisé à faire son select.
C’est ce « refuser » que j’essaie de trouver. La début de solution que
j’avais mise ne fonctionne pas !
Salutations
Re, Merci pour ta réponse, mais mon problème n'est pas tout à fait là: C'est plutôt comment gérer des verrouillages pessimistes. Par exemple : j’ai une fiche client que « A » est un train de manipuler en vue de faire une modification, je ne veux pas que « B » puisse y accéder.
à T1 « A » fait un select pour obtenir la fiche à T2 « A » manipule la fiche par le PGM de gestion la fiche doit restée bloquer en ecriture et voir en lecture, « B » veux accéder à la fiche refuser parce que « A » manipule la fiche. à T3 « A » fait son update, « B » est de nouveau autorisé à faire son select.
C’est ce « refuser » que j’essaie de trouver. La début de solution que j’avais mise ne fonctionne pas ! Salutations
Philip
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer soi-même les verrous pessimistes avec une table de sémaphores.
As-tu vraiment besoin d'un verrouillage pessimiste ? Dans une manipulation par interface graphique, il est préferable d'avoir un verrouillage optimiste -- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Philip" a écrit dans le message de news:
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer soi-même les verrous pessimistes avec une table de sémaphores.
As-tu vraiment besoin d'un verrouillage pessimiste ?
Dans une manipulation par interface graphique, il est préferable d'avoir un
verrouillage optimiste
--
Avec mes meilleurs voeux 2006
Med Bouchenafa
"Philip" <Philip@discussions.microsoft.com> a écrit dans le message de news:
12CECCE2-681C-4914-9439-9B6DD1D77ED1@microsoft.com...
Re,
Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer
soi-même
les verrous pessimistes avec une table de sémaphores.
As-tu vraiment besoin d'un verrouillage pessimiste ? Dans une manipulation par interface graphique, il est préferable d'avoir un verrouillage optimiste -- Avec mes meilleurs voeux 2006 Med Bouchenafa
"Philip" a écrit dans le message de news:
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer soi-même les verrous pessimistes avec une table de sémaphores.
le verrouillage pessimiste se gère par une transaction et un niveau d'isolation serializable mais c'est extrêmement pénalisant à partir de seulement quelques utilisateurs et il faut se méfier des verrous sur les index qui bloquent les recherches sur une série d'index
La meilleure façon de faire est en général un verrouillage optimiste et une relecture ou un contrôle par trigger au moment de la mise à jour.
br
"Philip" wrote in message news:
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer
soi-même
les verrous pessimistes avec une table de sémaphores.
le verrouillage pessimiste se gère par une transaction et un niveau
d'isolation serializable
mais c'est extrêmement pénalisant à partir de seulement quelques
utilisateurs et il faut se méfier des verrous sur les index qui bloquent les
recherches sur une série d'index
La meilleure façon de faire est en général un verrouillage optimiste et une
relecture ou un contrôle par trigger au moment de la mise à jour.
br
"Philip" <Philip@discussions.microsoft.com> wrote in message
news:12CECCE2-681C-4914-9439-9B6DD1D77ED1@microsoft.com...
Re,
Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer
soi-même
les verrous pessimistes avec une table de sémaphores.
le verrouillage pessimiste se gère par une transaction et un niveau d'isolation serializable mais c'est extrêmement pénalisant à partir de seulement quelques utilisateurs et il faut se méfier des verrous sur les index qui bloquent les recherches sur une série d'index
La meilleure façon de faire est en général un verrouillage optimiste et une relecture ou un contrôle par trigger au moment de la mise à jour.
br
"Philip" wrote in message news:
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer
soi-même
les verrous pessimistes avec une table de sémaphores.
D'abord merci à tous les deux, le Pb vient du faire également que notre base est très compacte, au plus fort une table contient au max 20000 enrgts et que nous avons une 50taine postes donc une forte proba. pour que deux utilisateurs se retrouvent au même moment sur le même enrgt. Sur de l'optimiste si je renvoie un message aux utilisateurs de bien vouloir refaire ce qu'ils ont fait car cela ne correspond plus parce qu'un autre à modifier quelque chose (les 3/4 du temps ils interviennent sur les même champs !), très rapidement je vais me faire "lyncher". Il est vrai que le pessimiste est plus pénalisant et qu'il faut mettre les utilisateurs en attente. C'est pour cela que j'ai fait ce post, "Mon coeur balance" si je puis le dire ! PL
Bonjour et mes meilleurs voeux 2006 également,
D'abord merci à tous les deux, le Pb vient du faire également que notre base
est très compacte, au plus fort une table contient au max 20000 enrgts et que
nous avons une 50taine postes donc une forte proba. pour que deux
utilisateurs se retrouvent au même moment sur le même enrgt. Sur de
l'optimiste si je renvoie un message aux utilisateurs de bien vouloir refaire
ce qu'ils ont fait car cela ne correspond plus parce qu'un autre à modifier
quelque chose (les 3/4 du temps ils interviennent sur les même champs !),
très rapidement je vais me faire "lyncher". Il est vrai que le pessimiste est
plus pénalisant et qu'il faut mettre les utilisateurs en attente. C'est pour
cela que j'ai fait ce post, "Mon coeur balance" si je puis le dire !
PL
D'abord merci à tous les deux, le Pb vient du faire également que notre base est très compacte, au plus fort une table contient au max 20000 enrgts et que nous avons une 50taine postes donc une forte proba. pour que deux utilisateurs se retrouvent au même moment sur le même enrgt. Sur de l'optimiste si je renvoie un message aux utilisateurs de bien vouloir refaire ce qu'ils ont fait car cela ne correspond plus parce qu'un autre à modifier quelque chose (les 3/4 du temps ils interviennent sur les même champs !), très rapidement je vais me faire "lyncher". Il est vrai que le pessimiste est plus pénalisant et qu'il faut mettre les utilisateurs en attente. C'est pour cela que j'ai fait ce post, "Mon coeur balance" si je puis le dire ! PL
lionelp
Bonjour,
L'utilisation d'un updlock (sur select) peut peut-être éviter de passer en sérialisable tout en garantissant le verrouillage d'un enregistrment donné.
Cordialement, LionelP
"Philip" a écrit :
Re, Après un tour chez les MSDN et SQLPRO, il s'avère qu'il faut gérer soi-même les verrous pessimistes avec une table de sémaphores.
