Discussion :

[kisame]

Bonjour tout le monde,

J'ai cherché dans la faq et quelques docs php, sûrement pas de manière exhaustive mais je ne trouve nulle part une info concernant les problèmes d'exclusion mutuelle en php.

Ca me pose un problème pour un singleton mais à la limite je me dis que c'est pas dramatique car je peux me passer du singleton dans mon cas. C'était juste pour retrouver mes habitudes javaiennes.

Problème : Ensuite, et là c'est plus gênant, si j'ai deux personnes ayant un compte admin qui veulent modifier la config du site via une page dédiée je n'ai trouvé aucun moyen réellement fiable pour répondre à un problème d'exclusion mutuelle classique. Pas de mutex, rien.

Si un tel mécanisme n'existe effectivement pas, j'ai bien d'autres solutions mais je les trouve moyennes.
- créer un fichier avec flock .... pb de droit chez l'hébergeur et je ne trouve pas ça top... on m'a toujours appris à ne travailler avec ce genre de solution qu'en dernier recours.
- Ajouter un champs dans une table qui va bien pour dire "article en cours d'édition par machin" ... seul problème : si la personne ne part pas correctement, la page reste lockée à moins de lier le tout à une session mais là encore la page ne risque pas de rester lockée inutilement trop longtemps ?. De plus, je ne sais pas comment faire "si session finie, mets à jour la BD en positionnant ce champs à faux".


bref que des solutions pas top. Je ne pense pas être le seul à mettre posé ce genre de question donc je fais appel à vos compétences pour m'aider

Je pense que le problème pourrait même faire partie d'une entrée dans la faq. Même si il n'y a pas de solution, au moins pour le dire. Ca peut intéresser plein de newbie en php comme moi qui ont l'habitude de travailler avec dans d'autres langage de manière native ou non.

Merci à toutes les personnes qui chercheront.

[koopajah]

La meilleure solution pour réaliser de l'exclusion mutuelle est d'utiliser flock si on n'a pas accès a une base de données, ou alors d'utiliser les instruction SQL de verrouillage d'une ou plusieurs tables quand on utilise une base de données.

Dans ton cas, il suffit donc que tu verrouilles en lecture/écriture les tables que tu es en train de modifier, ce qui correspond à une exclusion mutuelle, le second admin devra attendre la libération de la table pour la lire puis pour la modifier.

[kisame]

Ok, je redoutais un peu ce genre de réponse . J'aurais préféré un truc du style "achète des lunettes il existe un objet mutex avec une méthode lock et unlock tu le déclares en static et c'est fini et dans le code du destructeur un unlock est fait automatiquement" genre RAII pour ceux qui connaissent... en plus sympa bien sur . Enfin, je dis ça mais je te remercie pour ta réponse bien évidement tu l'auras compris

- Pour la solution à base de flock... ok. Avec les avantages et inconvénients dont j'ai déjà idée.
- pour l'autre solution, comme je ne suis pas très au fait de prog avec MYSQL, que se passe-t-il dans le scénario suivant (Je sais que je peux avoir l'info en cherchant mais je préfère que quelqu'un m'explique sur un exemple concret).

scénario tout simple
Une personne locke une ressource critique et quitte le programme de manière "malpropre" (reboot du pc, fermeture du navigateur, changement de page, etc...), donc aucun unlock n'est fait.

question : Sous qu'elles conditions le lock est levé ??? et donc est-ce que admin_a peut avoir acces à la table sans aucune intervention d'admin_b ?
--> http://dev.mysql.com/doc/refman/5.0/fr/lock-tables.html

* Table locks are released explicitly with UNLOCK TABLES.

* Table locks are released implicitly under these conditions:

- LOCK TABLES releases any table locks currently held by the thread before acquiring new locks.

- Beginning a transaction (for example, with START TRANSACTION) implicitly performs an UNLOCK TABLES. (Additional information about the interaction between table locking and transactions is given later in the section.)

- If a client connection drops, the server releases table locks held by the client. If the client reconnects, the locks will no longer be in effect. For this reason, clients may wish to disable auto-reconnect. With auto-reconnect in effect, the client is not notified if reconnect occurs but any table locks will have been lost. With auto-reconnect disabled, if the connection drops, an error occurs for the next statement issued. The client can detect the error and take appropriate action such as reacquiring the locks. See Section 23.2.13, “Controlling Automatic Reconnect Behavior”.

--> C'est le dernier point qui répond à ma question je suppose mais je n'en suis pas sur, donc déjà j'attends une confirmation de quelqu'un pour m'en assurer.
Ensuite, comment, s'assurer que la configuration est bonne et donc que le paramètre auto-reconnect est à false ? Quand je suis les liens sur l'auto-reconnect j'ai pas l'impression qu'on ait la main sur ça. Mais je ferai un test tout simple pour m'en assurer.

Donc pour ce problème simple et dans mon cas particulier... je pense que ça peut répondre à mon problème (merci koopajah), même si d'après ce que j'ai lu les lock et unlock de BD semblent aussi utilisés pour des raisons de performance (je me le note dans un coin ça d'ailleurs et je pense également qu'une petite entrée dans la faq MYSQL dans la partie performance peut être un plus également)

Maintenant, de manière plus générale :
- Comment réaliser ce principe dans un contexte de TRANSACTION ?
- Comment réaliser un lock pour une ligne et non toute une table ?


---

pour le deuxième point, car je vais y être confronté, j'ai vu dans joomla (je ne sais plus qu'elle version) comment ils ont résolu le problème. Ca a un très gros désavantage, si quelqu'un part malproprement, l'article reste locké (je l'ai vérifié)
En version simplifiée ça donne : dans la table qui regroupe tous les articles il y a un champs qui indique quel utilisateur a locké l'article. Si le champs ne vaut pas 0 alors l'article est libre sinon il est locké par la valeur que contient le champs ($id de l'utilisateur qui a lockée la ressource).
Sur le principe je trouve ça bien. Mais le problème c'est qu'il faut ajouter un truc du style "Si le client se déconnecte comme un porc libérer la ressource"... et ça je ne sais pas faire.

Merci d'avance à ceux qui feront des remarques, constructives bien sur

[koopajah]

Effectivement, dans le cas où quelqu'un peut verrouiller un article pour plus de quelques secondes, le verrouillage de table n'est pas envisageable (vu qu'il faut attendre que l'utilisateur modifie l'article ce qui peut lui prendre du temps).
Dans ce cas, la meilleure solution est de reprendre la technique de joomla en ajoutant un timestamp dans la base de données qui permet de savoir par qui ET à quelle heure l'article a été "verrouillé" et permet donc de récupérer d'un crash (un article verrouillé plus de x minutes sera déverrouillé.

[kisame]

La solution joomla complétée par un timer me semble pas mal. je vais creuser dans cette voie.

Merci pour tes remarques.

auto-critique :

Ca me pose un problème pour un singleton mais à la limite je me dis que c'est pas dramatique car je peux me passer du singleton dans mon cas. C'était juste pour retrouver mes habitudes javaiennes.

En php le problème de l'atomicité du "if(instance ==null)" du getInstance ne peut pas se poser, donc ma remarque n'est pas justifiée. voilou c'était pour corriger pour les éventuels futurs lecteurs.