Discussion :

[narutobaka]

Bonjour,

Je viens de lire ( plusieurs fois ) la documentation accessible ici :

http://sqlpro.developpez.com/cours/s...chniques/#L1.5

J'ai ainsi pu récupérer de précieuse information sur les accès concurrent ce qui a éclairé ma lanterne :

- Accès concurrents
- TRANSACTIONS
- diagramme du parallélisme des taches
=>définition des points de concurrence
- INSERT => SERIALIZABLE

Cependant j'avoue être complètement perdu qu'en à la démarche à utiliser pour mettre en place un traitement des accès concurrents.

Mon problème :

J'ai réfléchit à mon diagramme du parallélisme des taches et j'ai ainsi identifié à quels moments de l'utilisation de mon programme j'allais avoir la nécessité de gérer le problème des accès concurrents.

Mon application gère la saisie de formulaires . Ces formulaires sont mises à jour successivement à différent moment de leur vie, et dans certains cas la mise à jour d'une partie du formulaire peut-être accessible à plusieurs utilisateurs qui ont la tache de gérer ces mises à jour.

Je voudrais donc mettre en place une méthode qui empêche l'accès à un formulaire, quand un utilisateur effectue une action de mise à jour sur ce dernier, au autre utilisateur.

Je pense que c la qu'intervient la notion de transaction. J'utilise dans mon projet les procedures stockées pour effectuer les requêtes.

Première question :

Lorsque l'on execute une transaction en mode serializable sur un n-uplet d'une table ( un formulaire est un n-uplet dans mon application) quel(s) informations est renvoyée par une seconde transaction sur ce même n-uplet?

Reformulé : que va me renvoyé une requête d'update sur un n-uplet d'une table en cours de transaction.

Ceci pour pouvoir prévenir le deuxième ou le nième utilisateur, qu'un premier utilisateur effectue déjà le travaille et qu'il ne peux pas accèder à la mise à jour de ce formulaire.

Mon objectif étant d'empêcher tout autre utilisateur que le premier d'accèder à la mise jour d'un formulaire et d'informer coté php (client )que la mise à jour est déjà traiter par qqn.

Je sais pas si j'ai été clair.

Si qqn à une idée je suis preneur

Je continue mes recherches sur la valeur renvoyé par une requête effectué sur un n-upplet en cours de transaction.

++

[Ptit_Dje]

Hmmm... Perso je pense que ton cas n'a pas trop de rapport avec les access concurrants tels qu'on l'entend au niveau SQL Serveur.
Si j'ai bien compris ton idée, c'est un formulaire editable par un seul utilisateur à la fois.
Pourquoi ne pas rajouter un flag (bit) dans ta table genre : being_updated.
Si cette valeur est mise à 1, seul l'utilisateur qui est pour le moment en train d'updater le formulaire a le droit d'acceder à cette page.
Une fois le formulaire edité, remet le flag à 0.

Est ce que ca pourrait t'aller ?

[elsuket]

Je suis complètement d'accord avec Ptit_Dje, d'autant plus qu'une transaction ne doit pas attendre la réponse d"'un formulaire.
En fait elle ne doit pas attendre après des des évenements qui qui se produisent en dehors de la base de données.
Une solution propre est celle de Ptit_Dje.

A+

[SQLpro]

Étant l'uateur du document que vous citez, je me permet de vous "recadrer" !

Je pense que c la qu'intervient la notion de transaction. J'utilise dans mon projet les procedures stockées pour effectuer les requêtes.

Mauvaise interprétation !

Lorsque l'on execute une transaction en mode serializable sur un n-uplet d'une table ( un formulaire est un n-uplet dans mon application) quel(s) informations est renvoyée par une seconde transaction sur ce même n-uplet?

Le mode sérializable empêche toute modification sur toute la table. Si celle-ci fait 1 millions de ligne, alors toutes les lignes sont verrouillées en écriture et aucun utilisateur ne peut même y ajouter une nouvelle ligne ! Est-ce bien ce que vous voulez ? J'en doute !

que va me renvoyé une requête d'update sur un n-uplet d'une table en cours de transaction.

Rien, il attendra sagement, une heure s'il le faut, que la transaction précédente libère le verrou !

Ceci pour pouvoir prévenir le deuxième ou le nième utilisateur, qu'un premier utilisateur effectue déjà le travaille et qu'il ne peux pas accèder à la mise à jour de ce formulaire.

Vous voulez gérer du verouilage pessimiste alors qu'une base de données fait du verrouilage optimiste. Dans ce cas il existe différentes possibilités :

1) celle que vous dite qui est la pire. Autant ne travailler qu'en mono utilisateur ce sera plus sage !

2) celle que l'on vous a préconisé... Je n'en suis pas fan non plus, car en cas d'écran bleu de votre application cliente, le pseudo verrou ne sera jamais libéré...

3) l'implémentation d'une verrouillage pessimiste avec ticket. Le principe consiste à rajouter une colonne de type ROWVERSION. Comparer le ticket pris au début du processus avec celui fait dans l'update. Si c'est le même accepter la validation, sinon, rejeter la validation en levant une exception.

4) ne rien faire de tout cela car un SGBDR s'occupe du verrouillage et mode optimiste et c'est la meilleures des choses que de lui laisser faire son naturel. Des millions d'applications de part le monde utilisent ce principe et n'en sont pas mort... De quoi avez vous peu au juste ?

A +

[narutobaka]

bonjour,

et merci pour vos réponses.

Apperemment, voir même surement, j'ai du mal comprendre le concept d'accès concurrent à la base de donnée.

De quoi avez vous peu au juste ?

En fait ce que je voudrais pouvoir mettre en place, c un mécanisme qui empêche à un deuxième ou nième utilisateur d'accéder à une mise à jour d'un bon peinture qu'un premier utilisateur gère déjà.

Je viens de faire un test et apparemment seul la première saisie est prise en compte ( j'ai déjà un mécanisme qui indique que le bon n'est plus à cette étape de mise à jour si une mise à jour est effectuée)

Ce que je veux faire c enlever toute ambiguité possible.

Je vais essayer avec un champs booléen pour indiquer l'état d'un bon.

voilà voilà

je vous tiens au courant

[narutobaka]

Bonjour,

Je suis en train de mettre en place un système de verrouillage en utilisant un champs de type booléen qui passe à 1 si qqn traite le bon et à 0 lorsque le bon n'est géré par personne.

- Pour le verrouillage du bon pas de soucis.

Le problème vient de la gestion des différents cas de déverrouillage :

- Pour la démarche d'utilisation normal pas de soucis on repasse à 0 le bon lorsque l'utilisateur valide et donc libère l'accès au bon.

Mais il y a trois cas "exceptions" (peut-être d'autre auxquels je n'ai pas songé, si qqn en vois d'autre je suis preneur ):

- Fermeture du navigateur => il faut que je déverrouille avec un onbeforeunload
- Utilisation des boutons précédents et suivants du navigateur => il faut déverouiller avec unload

pour ces deux cas je travaille dessus.

Par contre le dernier cas :

- Le PC plante : comment gérer un "timeout" pour repasser à 0 le booléen au bout d'un certains temps.

Existe-t-il une méthodologie ?

je continue mes investigations ++

[ylarvor]

Je te propose la solution suivante:

A chaque mise à jour du formulaire sur le serveur, tu changes le TIMESTAMP.

Lors de la tentative d'écriture, si le TIMESTAMP de ton application web, ta version du formulaire, est différente de celle du Serveur SQL Server alors il est impossible de mettre à jour le serveur. Cela signifie que quelqu'un a fait la mise à jour avant toi et que tu dois recommencer ton travail depuis le début, rechargement puis réécriture. A toi de gérer le rafraichissement de ton application web avec les données du serveur.

Coté serveur, ce sera blindé! A chaque écriture, on update le TIMESTAMP et les données sont valides.

En fait, en cas de verrouillage optimiste, tu perdrais le travail de ton collègue, ici, tu perd ton travail, ce qui est tout de même plus facilement rattrapable.

[narutobaka]

Bonjour,

et merci pour ta réponse.

Si je comprend bien le mécanisme du timestamp il s'agirait d'une sorte d'identifiant unique que j'associerai au formulaire à mettre à jour.

Lors de la validation des données à mettre à jour je fait une comparaison entre le timestamp dans la base et celui associé à mon bon si il sont égaux je met a jour sinon je renvois un message indiquant que la mise à jour à déjà était traitée. Ai-je bien compris?

Cependant je me pose quand même une question quand à la génération du timestamp dans la base et quand à son utilisation.
Ce n'est pas encore clair pour moi.

Comment est généré le timestamp?
Dans la base avec la requête?
Qu'est-ce qui empechera un nième utilisateur de générer un timestamp sur le bon?
et le cas echéant comment libérer ( pour accèder à la suite du bon j'ai en effet plusieurs mise à jour à effectuer pour le même bon) le timestamp suite à son utilisation pour les autres mises à jour?

Si tu as un exemple je suis preneur d'utilisation je suis preneur

d'après mes recherches cela ressemble à l'idée que Sqlpro m'avait indiqué :

3) l'implémentation d'une verrouillage pessimiste avec ticket. Le principe consiste à rajouter une colonne de type ROWVERSION. Comparer le ticket pris au début du processus avec celui fait dans l'update. Si c'est le même accepter la validation, sinon, rejeter la validation en levant une exception.

mais je n'en suis pas sur.

voilà voilà je retourne faire mes recherches.

++

[narutobaka]

Bonjour,

Je vais laisser de côté ce "problème" qui n'en ai peut-être pas un et qui me prend du temps.

Actuellement j'ai un mécanisme qui gère les étapes de traitement d'un bon et empêche la mise à jour du bon si le bon n'est pas à cette étape. En faite suite à la mise à jour du bon l'étape du bon change et le traitement n'est plus possible pour l'utilisateur.

L'objectif de mon post était juste pour un confort d'utilisation de l'application, et ainsi ne pas faire perdre du temps à l'utilisateur qui va valider son bon et dont les données qu'il a saisit ne seront pas utilisé car le bon à déjà était validé.

Si un autre utilisateur tente de valider le bon après une première mise à jour il à un message lui indiquant qu'il ne peut pas le mettre à jour.

Mais je voulais avoir votre avis sur une chose :

Que se passe-t-il si deux utilisateurs valides le bon exactement en même temps. Comment va se comporter le SGBD dans le traitement des requêtes?
Est-ce que ca rentre dans ce cas ?:

4) ne rien faire de tout cela car un SGBDR s'occupe du verrouillage et mode optimiste et c'est la meilleures des choses que de lui laisser faire son naturel. Des millions d'applications de part le monde utilisent ce principe et n'en sont pas mort... De quoi avez vous peu au juste ?

voilà voilà

merci pour votre aide

++

[ylarvor]

SQL Server fonctionne par défaut en AUTOCOMMIT. Toute action est une transaction. SQL Server possède en interne un ensemble de mécanisme de verrous pour assurer la cohérence des opérations. Il existe une certaine permabilité des transactions et dans l'exemple que je te citais, il fallait utiliser un mode READ COMMITED entre le select et le update pour éviter qu'un utilisateur externe vienne pertuber la lecture entre le select et le update. La perméabilité permet de meilleures performances.