Discussion :

[robocop2776]

Bonjour,

Je suis en train de creer un projet en XUL, AJAX, JAVA, MySQL.
pour info XUL est un langage comme le HTML mais propre à Mozilla qui est plus riche en composant graphique et peut être insatllé sur le PC de l'utilisateur. La liaison entre le serveur et l'interface XUL se fait en AJAX. Ce projet est un logiciel de gestion multiutilisateurs et multiposte. Mon problème ne vient pas de la gestion multiutilisateurs mais multiposte.
Exemple:
2 utilisateurs se connecte sur le logiciel depuis 2 PC différents. Donc deux sessions sont enregistrer sur le serveur contenant les informations sur chaque utilisateurs. Jusque là tout est normal. L'utilisateur A visualise un enregistrement dans le but de le modifier. L'utilisateur B fait de même pour le même enregistrement. Et la je veux dire à l'utilisateur B que l'enregistrement est en lecture seule car l'utilisateur A est en train de le modifier. Donc j'ai penser pour toutes les tables indiquer si l'enregistrement est en cours de modification ou non (même si je trouve pas ca propre). Avec cette solution un problème survient. Imaginons que l'ordinateur de l'utilisateur A plante et quitte donc le logiciel anormalement. Mon enregistrement se trouvera alors toujours en mode modification.

Y a t-il une méthode pour faire une application mutiplateforme.

merci d'avance

[comico]

Une solution est stocker le datetime du "pseudo lock" (et/ou un id de session si l'on gère soi même les sessions en base) et de gérer un "pseudo timeout" par l'application.

L'utisateur selectionne un enregistrement locké mais c'est un lock datant de plus de x minutes donc on considère que ce lock est obsolète et on n'en tient pas compte (ou/et on le supprime). Il n' y a pas de solution miracle en déconnecté. Il convient avec ce système de vérifier avant de poster des modifications que le pseudo lock du record correspond bien à la session en cours (afin de pouvoir gérer l'utilsateur qui est parti déjeuner, qui avait obtenu le "lock", qui l'a cédé du fait du time out et qui, revenu de déjeuner veut valider son formulaire...) .

Certains préfèrent un système à base de N° de version d'enregistrement, bon tout cela revient un peu au même (notamment vérifier avant de poster que l'enregistrement n'a pas été modifié entre temps). On cherche à éviter les conflits préventivement (mode pessimiste) mais on est également contraint de les résoudre lors de la validation (mode optimiste)

Bon on peut aussi parfois s'appuyer sur les possibilités de lock record du SGBD (cf SELECT ... FOR UPDATE) mais il faut réserver cela aux transactions très courtes (incrémenter un compteur par exemple)

S'il y a mieux cela m'intéresse aussi :-)