Gestion de conflits multi clients

Bonjour,

Je développe une application Flash et Php/MysQl où plusieurs clients sont susceptibles d'écrire ou éditer en même temps des enregistrements similaires de certaines tables, ce qui n'est pas judicieux bien évidemment. Je voudrais comprendre à quel niveau une interdiction d’accès pourrait se faire si l'enregistrement est déjà en cours d'utilisation. Cela se gère t-il au niveau de l'application client ou bien de mes scripst php?

- Je pensais mettre un flag d’édition sur mes enregistrements (un booléen à 0 ou 1 selon s'ils sont en cours d’édition ou non) mais le mécanisme de vérification avant de permettre l'écriture fait faire pas mal d'aller retour entre la bdd et le client :?
- Une autre idée était d'utiliser Electroserver et connecter tous les clients par un socket. Ainsi le niveau d'intervention de chaque client sera connu et les conflits évités par le script server. Mais là j'ai peur de ne pas être assez calé :aie:

J'espère que quelqu'un a une suggestion plus simple à m'offrir! Merci par avance

Bonjour,
J'ai toujours eu des problèmes avec des systèmes de locking sur des éléments. Les questions qui se posent sont toujours les mêmes : quel système utiliser pour "unlock" les éléments en cas de crash ou de fermeture du browser ? et effectuer cette tâche après combien de temps ?

Personnellement j'utilise généralement une approche optimiste. L'utilisateur choisi l'élément à éditer et l'affiche dans le formulaire du navigateur. Au moment de la sauvegarde, à l'intérieur d'une transaction du SGBD, je vérifie que personne ne soit venu écrire depuis le chargement de l'objet (comparaison sur un champ de date LAST_MODIFICATION par exemple, ou d'un numéro incrémental d'édition). Si par hasard l'enregistrement a été modifié, levée d'une exception indiquant à l'utilisateur qu'il a malheureusement perdu ses modifications et qu'il devra recommencer ;)

La gestion de l'erreur peut être affinée, par exemple en faisant une comparaison sur chaque champ de l'élément édité et de présenter à l'utilisateur les deux versions pour qu'il fasse un choix. Ce mécanisme de gestion est toutefois très lourd à gérer.

Bon courage pour votre réflexion sur cette problématique compliquée (surtout pour un protocole stateless comme HTTP couplé avec un langage de scripting comme PHP).