PHP, MySql et multi utilisateur

Le
Marc Mendez
Bonjour,

J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
La première mouture qui fonctionne depuis deux ou trois ans ne se préoccupe
pas du multi utilisateur. En fait, "le dernier qui parle à raison" comme on
dit.

Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).

Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.

Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )

Merci de vos conseils.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Mickael Wolff
Le #63446
Bonjour,

J'ai une application métier fonctionnant sous Internet, en PHP et MySql.


Aïe. Vous êtes le développeur ?

Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).


Ça n'a rien à voir. De plus, il existe un rowid dans les tables MySQL.

Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql... mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.


Mauvaise idée.


Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )


Il faudrait avoir le code sous les yeux pour pouvoir donner un avis
pertinent. À coup sûr il faut sérieusement revoir l'architecture de
l'application pour la rendre multi-utilisateur, et introduire les locks
là où il faut. Et sans que ce ne soit bloquant.

Mais là, ce n'est pas un problème de PHP, mais un problème de design.

--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

Bruno Desthuilliers
Le #63441
Bonjour,

J'ai une application métier fonctionnant sous Internet, en PHP et MySql.
La première mouture qui fonctionne depuis deux ou trois ans ne se préoccupe
pas du multi utilisateur. En fait, "le dernier qui parle à raison" comme on
dit....

Vu que l'appl fonctionne sous un navigateur, il est difficile de maintenir
un verrou sur les données courament affichées à l'écran. De plus, à la
différence d'autres SGBDR (Oracle par exemple), il n'y a pas de notion de
ROWID permettant de savoir si une données a été modifiée depuis la dernier
consultation (et encore, certains SGBDR ne le changent pas en cas d'update).

Je verrai bien un lock sur les données, avec un timeout sur le serveur
MySql...


C'est peut être un a priori, mais j'aurais pas confiance.

mais j'en suis au stade pur des supposition. Mes recherches sur le
sujet n'ont pas été concluante.

Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre : niet ;) )


Ce n'est pas à proprement parler un pb de langage - le pb serait le même
en Perl, en Python, en Ruby, en Java, etc, etc, etc...

Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est passée
via un input hidden au formulaire d'édition, et vérifiée au retour du
formulaire pour détecter une modif intervenue entretemps.

Marc Mendez
Le #63149
Bruno Desthuilliers wrote:
Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est
passée via un input hidden au formulaire d'édition, et vérifiée au
retour du formulaire pour détecter une modif intervenue entretemps.


Bonjour,

C'est effectivement une solution à laquelle j'ai pensé. Le timestamp pourra
d'ailleurs être maintenu automatiquement par des triggers.

Marc Mendez
Le #63150
Mickael Wolff wrote:
Bonjour,

J'ai une application métier fonctionnant sous Internet, en PHP et
MySql.


Aïe. Vous êtes le développeur ?


De la version courante, non. De la prochaine, en grande partie...

Quelles solutions voyez-vous ? Je présime que nous ne souhaitons pas
utiliser d'autres langage que le PHP (donc Delphi, Java ou autre :
niet ;) )


Il faudrait avoir le code sous les yeux pour pouvoir donner un avis
pertinent. À coup sûr il faut sérieusement revoir l'architecture de
l'application pour la rendre multi-utilisateur, et introduire les
locks là où il faut. Et sans que ce ne soit bloquant.


Ma foi, les requetes ne manquent pas. En gros, il y a deux méthodes :

l'une consiste à lire toutes les données nécessaires en début de la page
(elles sont stockées en tableau), et éventuellement de faire les premiers
traitement sur les données. Ensuite, affichage.
Les modifications sont faites en appelant à partir de cette première page,
une autre page qui se charge de récupérer les infos passées en post et fait
les modifs dans la base.

L'autre méthode fonctionne sur une seule et même page qui collecte, affiche
et modifie les données.


Je vois très bien comment conserver le timestamp des lignes éventuellements
(input caché). Ensuite, à moi de m'assurer que les UPDATE fasse une
modification ligne par ligne et pas par lot (sinon impossible de contrôler
le timestamp de chacune... et encore, ça dépendra peut-être du contexte...)

Bref, de toute façon, votre réponse et celle d'autres personnes m'ont
confirmé les solutions à mettre en oeuvre. La réécriture de l'application
est incontournable de toute façon pour ce genre de prise en compte... En
plus, elle doit être réécrite car la structure des données que nous
utilisons ont foncièrement changé et elle ne couvre plus ainsi tous nos
besoins.

Merci de votre réponse !

Mais là, ce n'est pas un problème de PHP, mais un problème de design.



Bruno Desthuilliers
Le #63148
Bruno Desthuilliers wrote:
Une solution assez simple consiste à utiliser une colonne avec un
timestamp conservant la date de dernière modif. Cette valeur est
passée via un input hidden au formulaire d'édition, et vérifiée au
retour du formulaire pour détecter une modif intervenue entretemps.


Bonjour,

C'est effectivement une solution à laquelle j'ai pensé. Le timestamp pourra
d'ailleurs être maintenu automatiquement par des triggers.


Pas nécessaire si version de MySQL suffisament récente - il suffit de
déclarer correctement le champ pour qu'il se mette à jour tout seul sur
un update.


Publicité
Poster une réponse
Anonyme