[PHP/Mysql] consult./modif. d'une même fiche par plusieurs utilisateurs simultanés [Résolu]

[Amanck]

Bonjour,

Je suis autodidacte et on m'a confié une lourde tache : réaliser une base de données pour un service, accessible sur plusieurs postes et par plusieurs utilisateurs simultanément.

Après m'être renseigné auprès de différentes sources (internet, relations personnelles), j'ai suivi leurs conseils et opté pour Mysql/Apache/PHP.

Pour le moment ça avance (pas mal à mon goût, trop lentement au goût des commanditaires ).
Je me pose cependant une question (peut-être un peu prématurée ?) :

Comment faire pour permettre à deux (ou plus) utilisateurs simultanés d'accéder à la même fiche avec, par exemple, le premier connecté à la fiche pouvant la modifier, et le second ne pouvant que la consulter (dans ce cas, les modifications apportées par l'autre utilisateur n'apparaissent pas) ?

J'ai probablement d'autres chats à fouetter avant d'attaquer cet aspect des choses, mais sur ce point, je n'ai absolument aucune piste pour le moment.

Merci de vos réponses,

Cordialement

[titoumimi]

je pense que je me contenterai de mettre une variable à 1 dans ma DB pendant l'édition, ainsi qu'une heure de vérouillage.

On dévérouille au choix si le temps est passsé, ou une fois l'édition terminée

[Fladnag]

tu as plusieurs possibilités pour gerer ca.

La solution proposée par titoumimi est une solution du genre :

User1 demande la modification (acces a l'ecran de mise a jour) :
UPDATE table SET lock=1, dateLock=NOW() WHERE ID=... AND lock=0

User2 demande la modification :
UPDATE table SET lock=1, dateLock=NOW() WHERE ID=... AND lock=0 => Aucune ligne mise a jour : on affiche un message disant qu'on ne peux pas le faire parce qu'un autre user le fait

une fois que User1 a fait sa modif, on fait :
UPDATE table SET lock=0 WHERE ID=... AND lock=1

MAIS cela demande de gerer un timeout comme il le dit... car si User1 ferme son navigateur, le champ sera locké a jamais...
Donc c'est a toi de faire quelque chose comme :
UPDATE table SET lock=0 WHERE ID=... AND dateLock <...

Problemes possibles :
User1 lock et va manger
le timeout arrive
User2 lock a son tour grace a l'expiration du timout
User1 revient et valide => La modif est faite et on repasse lock=0
User2 valide => La modif écrase la précédente (sauf si on ajoute "AND lock=1" dans l'update des données comme dans la solution du lock optimiste expliqué plus bas)

Tu peux resoudre cela en stockant l'ID de l'User dans chaque table aussi... mais ca commence a bien surcharger la table... et ca protege pas d'une double session avec le meme User non plus ;o)

Une autre solution est ce qu'on appelle le lock optimiste, et il a l'avantage de ne pas avoir besoin de gerer de timeout.

L'idée c'est de gerer dans chaque objet un "numero de version" qui est un bete int.
Lorsque l'objet est créé, version=0
Lorsque l'objet est lu, le numero de version est sauvegardé (dans un champ hidden ou dans la session utilisateur)

Lorsqu'on veux modifier un objet, on utilise :

UPDATE table SET ..., version=version+1 WHERE version=$versionLue

Exemple :
User1 lit l'objet => version=0
User2 lit l'objet => version=0
User1 modifie l'objet (une seule requete UPDATE, unicité) => version=1
User2 modifie l'objet => l'UPDATE ne se fait pas car il cherche a modifier l'objet en version=0 et version a été modifié. User2 perd donc ses modifs mais il est averti que la raison en est que l'objet a été modifié entre temps.

Cela marche bien si il y a peu de modifications... et c'est très léger a gerer je trouve ;o)

Si tu as plusieurs tables a mettre a jour en meme temps, tu peux aussi include l'ensemble des modifications dans une seule transaction grace a LOCK TABLE

[Amanck]

Un grand merci à vous deux pour vos réponses rapides et très explicites (Fladnag).
Je vois mieux vers où aller maintenant (même s'il faut que je "digère" toutes ces infos : comme je le disais au début du 1er post, j'apprends au fur et à mesure que j'avance et grace à des forums et des sites comme le votre, j'avance plus vite ).

Très cordialement,

@+

[titoon]

Tu peux aussi ajouter un champ "date_derniere_modif" avec la ... date et l'heure de la dernière modif, que tu passes en champ hidden dans ton formulaire de modification. Si la date en base est identique à la date du champ hidden, l'objet n'a pas été modifié donc la modification peut être faite, sinon, tu ne modifies pas l'objet (puisque quelqu'un à déjà modifié l'objet avant)

Je sais pas si j'ai été très clair, donc petit exemple :
on suppose date = 1
utilisateur 1 accède à la fiche de l'objet : date en base = 1 ; date du formulaire = 1
utilisateur 2 accède à la fiche de l'objet : date en base = 1 ; date du formulaire = 1
utilisateur 1 valide sa modif : date du formulaire = 1 ; date en base = 1 ; validate de la modification de l'objet ; nouvelle date en base = 2
utilisateur 2 valide sa modif : date du formulaire = 1 ; date en base = 2 ; annulation de la modification

[Fladnag]

sauf erreur de ma part, c'est exactement la meme chose que mon champ "version" titoon ;o) c'est un lock optimiste. Utiliser une date au lieu d'un int peut etre utile "en plus" pour savoir quand l'objet a été modifié. Utiliser un int permet de savoir par contre combien de fois l'objet a été modifié

[titoon]

Ooops, j'avais pas lu la partie "lock optimiste" de ton post...