Blocage de fiche et alertes

**Elyoukey** · 30/01/2006, 16h09

Bonjour,
je suis surpris de ne rien trouver la dessus, donc je me dis que je passe sans doute à coté de quelquechose d'énorme... :/

Voila, mettons que j'ai une base MySQL avec une table personnes dedans.
Un premier utilisateur (Alphonse) ouvre une fiche, fais des modifications, et part prendre son café.
Un deuxième utilisateur (Bernard) à partir d'un autre client ouvre la même fiche.

Y'a til un moyen élégant de récuperer l'info qui dit que Alphonse a ouvert la fiche et donc d'empecher Bernard de la modifier ?

Pour l'instant ce que j'ai trouvé de plus proche c'est de rajouter un champ timestamp dans la table :

http://www.developpez.net/forums/vie...hlight=bloquer

Mais ça ne correspond pas tout à fait à mon problème. Et je trouve cela un peu 'lourd' dans la mesure où les tables innoDB peuvent bloquer à la fiche avec l'instruction 'for update'.

Mon instinct me dis que c'est un problème récurant chez tous les développeurs qui commencent une application...

D'avance merci pour tout début de piste ou bribe d'information, (... ou application complète avec code source ouvert)

**Maximil ian** · 30/01/2006, 18h00

Bonjour,

En effet la gestion des transactions (car c'est ce dont il s'agit) est un grand classique des SGBD. Tu trouveras un topo complet sur la question ici.

Par contre on peut se poser la question de la pertinence d'un système qui bloque une ligne voire une table (MyISAM) pendant X minutes juste parce que la personne est partie prendre un café

D'ailleurs dans un contexte Web ce n'est en général pas possible...

**pcaboche** · 30/01/2006, 18h25

Envoyé par Maximilian

D'ailleurs dans un contexte Web ce n'est en général pas possible...

En fait, il faut que ce soit prévu par l'application: un message d'alerte disant que la version sur le serveur est plus récente que la version que l'on est en train d'éditer. Cela n'est pas vraiment un problème de transactions mais plus un problème d'interaction avec la base de données (ex: il faut un certain temps pour répondre à un message sur le forum, pendant ce temps-là, plusieurs personnes peuvent poster des messages).

**Maximil ian** · 30/01/2006, 19h23

Envoyé par pcaboche

Envoyé par Maximilian

D'ailleurs dans un contexte Web ce n'est en général pas possible...

En fait, il faut que ce soit prévu par l'application: un message d'alerte disant que la version sur le serveur est plus récente que la version que l'on est en train d'éditer. Cela n'est pas vraiment un problème de transactions mais plus un problème d'interaction avec la base de données (ex: il faut un certain temps pour répondre à un message sur le forum, pendant ce temps-là, plusieurs personnes peuvent poster des messages).

Tout à fait, je disais "en général" car on peut tout de même utiliser des connexions persistantes à la base de données pour faire des transactions plus longues (sinon la connexion est fermée à la fin de l'exécution de chaque page dynamique)

**Elyoukey** · 31/01/2006, 09h33

Envoyé par Maximilian

Bonjour,
[...]
Par contre on peut se poser la question de la pertinence d'un système qui bloque une ligne voire une table (MyISAM) pendant X minutes juste parce que la personne est partie prendre un café

D'ailleurs dans un contexte Web ce n'est en général pas possible...

Merci de la réponse, J'ai fait une première lecture, et je ne vois pas clairement comment résoudre le problème des écrans de saisie. En effet, les transactions sont efficaces si deux utilisateurs cliquent en même temps, et les processus concurrents.
En l'occurence, j'ai deux utilisateurs qui visualisent une fiche, et valide à 5 minutes d'intervalle. Les processus de validations ne sont donc pas du tout concurrents.

pcaboche est dans le vrai, c'est l'interaction avec la base qu'il me manque.
Donc à part coller un timestamp dans chaque table, comment faire pour prévenir l'utilisateur lorsqu'il ouvre une fiche (SELECT gnagna from schmoluk) qu'il y a un autre utilisateur qui l'a ouverte et soit lui bloquer la validation soit le prévenir que son collègue va lui en vouloir d'avoir effacé les 3 heures de boulot (et sans doute lui crever les pneus en guise de représaille)

J'arrive (environ) à commencer une transaction pour Alphonse, et en restant connecté tout le temps de la modif, Bernard ne peut pas faire de mise à jour
Mais je ne connais pas la commande qui va dire attention, il y a quelqu'un de connecté sur cette fiche, histoire que Bernard n'ai pas à attendre le time out de 2heures (que je ne sais pas regler non plus d'ailleurs) et puisse faire autre chose en attendant.

PS, je ne suis pas dans une architecture web, donc je peux garder la connection à la base durant le temps de visualisation et modification.

**pcaboche** · 31/01/2006, 10h16

Envoyé par Elyoukey

Mais je ne connais pas la commande qui va dire attention, il y a quelqu'un de connecté sur cette fiche, histoire que Bernard n'ai pas à attendre le time out de 2heures (que je ne sais pas regler non plus d'ailleurs) et puisse faire autre chose en attendant.

C'est pourtant simple: tu fais ta requête normalement, puis tu lis la date de dernier accès au fichier pour modification. Tu compares cette date à la date courante: si il s'est écoulé suffisamment de temps depuis le dernier accès pour modif, tu affiches le formulaire de modif, sinon tu affiches un message d'erreur lui disant de patienter.

Tu peux vérifier que l'édition est possible directement en MySQL (exemple avec un intervalle de 30 min):

Code :

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

1
2
3
4
SELECT
  (heureAccesModif IS NULL OR 
  NOW() < DATE_ADD(heureAccesModif, INTERVAL 30 MINUTE)) AS EditionPossible
...

Maintenant, imaginons que la personne édite un document, son patron débarque dans son bureau pour lui demander quelque chose de "super urgent à faire pour avant-hier" et donc l'employé perd 2h à faire autre chose. Deux heures plus tard, il va pour soumettre les modifications mais entre-temps quelqu'un d'autre a éditer le document. Il faut éviter ce cas de figure et montrer à l'employer 2 choses:
- la dernière version du document
- ses propres modifications
afin qu'il puisse intégrer ses modiifications dans la nouvelle version du document.

Si entre-temps une 3ème personne accède au document pour modifications, il faudra attendre.

Au moment où les changements ont été effectué, il faut supprimer ce "verrou" de modification (d'où le IS NULL dans la requête SQL précédente). Pour la gestion des "verrous", tu peux avoir recours à une nouvelle table (en effet, les "verrous" ne sont pas une propriété du document et servent uniquement à la gestion des accès par l'application).

Il te faut donc deux dates:
- la date de dernière modification de document
- la date de dernier accès pour modification (peut être NULL)

Enfin, tu peux intégrer les scenarii décrits précédemment à ton chaier de recettes (ah... ce bon vieux cycle en V !).

**Elyoukey** · 31/01/2006, 10h49

Merci pcaboche pour ce 'howto' complet.
Mais (parce qu'il y a toujours un mais) ça ne me parait pas 'optimum'.

D'une part, parce que je suis obligé de rajouer un champ à toutes mes tables, ou de créer une table exprès rien que pour ça alors que la BDD sait pertinement qu'il y a une transaction d'ouverte sur la fiche puisqu'elle attend et finit par me balancer un message d'erreur dans ma face (qu'est ce que c'est irritant une BDD).

D'autre part, cela rajoute une quantité de code non négligeable qui est fatalement source de bug, avec jonglerie algorythmique source de ralentissements.

Enfin, je reste étonné qu'il n'existe pas déja des solutions 'toute faite' à partir de la BDD pour réserver une fiche et communiquer aux autres utilisateurs que la fiche est reservée/utilisée... Je m'en va relire le lien de maximilian.

**Maximil ian** · 31/01/2006, 11h30

Un extrait de ce lien qui va dans le sens de ce que je disais plus haut :

L'idée de manipuler des transactions depuis un code client (VB, Delphi, Java, C++...) est séduisante mais "casse gueule" et peut entraîner le pire du pire : un blocage total du serveur. En effet dès que l'on entame une transaction, le SGBDR pose les verrous adéquats sur les ressources visées par la procédure. Si le client perd la main sur son code et ne provoque jamais de COMMIT ou ROLLBACK, les ressources ne sont pas libérées et entraînent l'impossibilité pour les autres utilisateurs d'accèder aux données vérouillées. C'est pourquoi une logique transactionnelle doit toujours être exécutée au plus près du serveur et non sur le poste client, à moins que vous ayez prévue l'artillerie lourde : poste sur onduleur on line ou réseau électrique sur alimentation secourue, OS hyper stable, anti virus, etc...

De plus, il convient que la procédure ne soit jamais en attente d'une manipulation de l'utilisateur (comme une demande de saisie ou de confirmation) car toute attente bloque les ressources un certain temps et met en attente d'autres utilisateurs. C'est alors le château de carte, chaque utilisateur attend qu'un autre libère les ressources et cela peut entraîner le blocage total du SGBDR, par exemple un verrou mortel...

**Elyoukey** · 31/01/2006, 11h53

donc si je comprends bien,

-gérer les transactions 'à la main' coté client, c'est source de problème

-faire la gestion coté BDD ok, mais il ne faut pas que les transactions durent longtemps, il faut que ce soit dans des procedures ponctuelles (qui n'attendent pas que Alphonse ai fini son café)

Mais alors comment font les autres ?
On est obligé de rajouter une couche de programmation pour gérer les accès à des fiches ? Sans passer par les transactions de la base de donnée ? (c'est un peu bizarre je trouve d'avoir un système de blocage, mais de ne pas s'en servir)

Bref, j'ai un peu l'air de me répeter, mais tous (la plupart) des logiciels fonctionnent avec l'algorythme de pcaboche ?!?? ça me parait être une énorme masse de code pour une info que l'on pourrait avoir facilement non ?

:

**pcaboche** · 31/01/2006, 13h01

Envoyé par Elyoukey

D'une part, parce que je suis obligé de rajouer un champ à toutes mes tables, ou de créer une table exprès rien que pour ça alors que la BDD sait pertinement qu'il y a une transaction d'ouverte sur la fiche puisqu'elle attend et finit par me balancer un message d'erreur dans ma face (qu'est ce que c'est irritant une BDD).

Là, je suis plutôt complètement d'accord avec Maximilian !

Envoyé par Elyoukey

On est obligé de rajouter une couche de programmation pour gérer les accès à des fiches ? Sans passer par les transactions de la base de donnée ? (c'est un peu bizarre je trouve d'avoir un système de blocage, mais de ne pas s'en servir)

C'est surtout que les transactions ne servent pas du tout à ça: elles servent à assurer l'intégrité des données lors de l'exécution concurrente de scripts. Pour faire simple, cela revient à dire: "cet ensemble d'instructions doit être vu comme un tout et le script doit être exécuté en intégralité, sans interruption, ou alors on doit pouvoir revenir dans l'état précédent l'exécution (ROLLBACK)".

**Maximil ian** · 31/01/2006, 13h12

Si j'ai bien compris, tu as comme règle métier que deux personnes ne peuvent pas consulter la même "fiche" en même temps. Je peux me tromper, mais ce n'est pas si courant (en tout cas je ne l'ai jamais rencontré).

Donc effectivement la méthode de pcaboche me parait adaptée.

Edit :

Ca serait une bonne idée de poster sur le forum de ta techno/langage pour avoir plus d'avis.

**Elyoukey** · 01/02/2006, 10h02

Envoyé par Maximilian

Si j'ai bien compris, tu as comme règle métier que deux personnes ne peuvent pas consulter la même "fiche" en même temps. Je peux me tromper, mais ce n'est pas si courant (en tout cas je ne l'ai jamais rencontré).

non, deux personnes peuvent consulter la même fiche, mais lorsque la deuxième personne arrive, il faut lui indiquer que la fiche est en cours de modification et bloquer la possibilité de modifier. (On a des secrétaires qui font de la saisie sur des fiches avec beaucoup de champs, donc ça prend du temps). Comme sur un serveur de fichier : "Attention, le fichier Schmoluk_vert.xls est en cours d'utilisation par Madame Viala".

ça me parait assez classique comme façon de faire, mais je n'ai jamais eut à l'implémenter. Et il me paraitrait logique qu'une base de données sache gérer cela. Mais sans doute que je me fourvoit quelquepart ...

Envoyé par Maximilian

Edit :
Ca serait une bonne idée de poster sur le forum de ta techno/langage pour avoir plus d'avis.

Ben là c'est notre deuxième problème, c'est qu'on a pas vraiment choisi de langage, pour l'instant notre application fonctionne sur 4eme Dimension (que ceux qui connaissent tappent des pieds) et on veut la migrer. 4D gère ce point particulier sans problème.

On est parti sur une base MySQL, et un frontal non choisi encore. Donc je regardes jusqu'où on peut aller avec MySQL pur. Je suis preneur de toute info.

en tous cas, merci pour votre patience.

**Elyoukey** · 02/02/2006, 12h17

En résumé,

-est-ce que la 'saisie de fiche' par un utilisateur peut être gérée par la base de donnée MySQL ?

et si oui comment ?

**pcaboche** · 02/02/2006, 13h16

En résumé,

non.

**Elyoukey** · 02/02/2006, 13h47

ok, la réponse est claire.
Mais (on a dit que y'avait toujours un mais)
pourquoi ?

et
y'a t'il des SGBD qui le gèrent ?

(je vais essayer de cocher la case reglé, parce que à partir de là c'est du surplus, mais vous pouvez continuer à répondre)