Blocage d'une donnée lors de son édition

Bonjour,

Je travail actuellement sur un projet web php/firebird dans lequel de nombreuses personnes pourront accéder à des ressources communes.
Il se pose donc le problème du blocage de ces ressources, en effet il ne doit pas être possible de modifier une donnée si celle ci est en train d'être modifiée par quelqu'un d'autre (à la mode gestion des articles joomla CMS).

J'ai donc tout d'abords pensé à ajouté à l'enregistrement de la donnée en question dans la BDD un champ 'EnCoursDeModification' qui se comporterais comme un peu comme un mutex (on check si on peut entrer ou non ). Mais le super truc nul qui fais que cette super idée est super pas super du tout, c'est que si monsieur trucmuche entre dans le mode édition et qu'il ne le referme pas, eh bien tous les monsieurs trucquelquechose ne pourront pas accéder à la donnée après cela.

Donc voila je suis un peu coincé, j'ai pas trop d'idées , en plus avec les sessions de php (d'après ce que j'ai compris, maintenant si je me trompe tant mieux) , on ne peut accéder qu'à la session de l'utilisateur courant.

Si quelqu'un a déja résolu ce problème ce serait cool de me filer qlq tips.
merci d'avance :D .

Tu peux utiliser ajax pour faire en sorte que quand la personne s'en aille ça vide le champ encoursdemodification.

Evenement 'unload' de javascript, qui pointe sur un fichier php resetant le champs en bdd.

En effet ce serait une bonne solution. Mais le problème avec javascript c'est que ça dépend trop du client pour y accorder toute sa confiance.
C'est pour cela (et je suis navré j'aurais du le préciser) que je recherche une solution côté serveur.
En fait les données que j'ai à traiter sont assez sensibles (médicales) et je tiens à ce que les vérifications et traitements se fassent sur le serveur (le pauvre il aura du taf ).

En tous cas merci de ta réponse (je n'y avais pas du tout pensé) , je pourrais mettre ça en place comme un plus.

Ce qui me rend très jaloux, c'est que sous joomla ils arrivent à gérer ce problème (gestion des articles ) mais je ne crois pas être assez expérimenté pour chercher dans leur supra méga gros code comment il font...

Voila conclusion si quelqu'un aurait une idée pour gérer ca côté serveur... :D

Citation:

---

monsieur trucmuche entre dans le mode édition et qu'il ne le referme pas

---

Les CMS utilisent justement unload.

Sinon, purement coté serveur, tu peux pas savoir quand l'user quitte la page.
Tu peux faire un include dans chaque page qui vide les éditions en cours du membre (placé avant le code qui met à jour le champ dans la bdd dans le script d'édition d'article, évidemment).
Couplé avec le unload, ça devrait pas donner lieu à trop de problème.

Mais quoiqu'il en soit, tant que le mec referme pas c'est logique que personne puisse éditer.

Ok, oui tu as raison de toutes manières.
Je pense que je vais utiliser la technique que tu m'a donné, je ne savais pas qu'ils géraient le problème de cette manière dans les CMS.
Ce que je vais peut être faire c'est mettre en place en plus un service qui se charge de débloquer les données bloquées depuis vachement beaucoup de temps, il faudra par contre veiller à la formation des utilisateurs pour éviter ça...

Bah en tous cas merci beaucoup pour tes réponses c'est très chouette de ta part . :)

Citation:

---

plus un service qui se charge de débloquer les données bloquées depuis vachement beaucoup de temps

---

Ouais, c'est ce que je fais.
Je débloque tout ce qui a été en cours d'édition depuis plus d'une heure.

De rien, et bon courage.

Salut,
jette un coup d'oeil aux SGBD transactionnels et aux verrous. Si tu veux gérer tes verrous à la main tu peux stocker un délai de verrouillage. Si le délai est dépassé tu débloques. Bye

Il parle de bloquer aussi visuellement, le sql transactionnel n'a rien à voir avec ça.

Bin si tes lignes sont verouillées tu balances un message au client. C'est pas ça qu'il veut ?
Si t'es sous MySQL, InnoDB gère les SELECT FOR UPDATE : http://dev.mysql.com/doc/refman/5.0/...ing-reads.html

Pas si sur qu'il soit en InnoDB, et en plus il parle d'éditer un article, donc pendant que tu lis et édite ton article les autres accèdent pas, pas pendant que le sgbd écrit ou lit des données dans la base.

Et pas

Citation:

---

Une commande SELECT ... FOR UPDATE va lire les dernières données disponibles pour chaque ligne, et pose un verrou dessus en même tant qu'il lit

---

Oui voila en fait je ne cherche pas à mettre un verrou type exclusion mutuelle sur l'écriture d'une donnée (comme en multi thread) seulement lorsque la requête va chercher les données mais un verrou qui empêche aux utilisateurs d'enter dans la page d'édition de cette donnée lorsqu'elle est en train d'être modifiée par quelqu'un d'autre (cette personne visite elle aussi le page d'édition).

Donc je pense pas que ce sois la bonne solution, je pense encore une fois que je vais mettre en place la technique en ajax et puis un service qui débloque les données qui sont en cours de modification depuis un temps supérieur à celui de la durée de vie d'une session.

Et puis en plus j'utilise Firebird et j'ai pas vu d'histoire de moteur de stockage comme sous MySQL ...

Merci quand même :D