Gestion des accès concurrents dans une base MySQL

Bonjour à tous
Actuellement, je suis la seule personne qui gère le contenu de la base, les autres personnes n'y accèdent qu'en lecture, je n'ai donc pas écrit de code pour gérer les accès concurrents en écriture.
J'envisage d'ouvrir cette possibilité à quelques personnes et j'ai donc besoin de vos conseils.

La table Location contient la description d'un lieu où le groupe tient des activités,
la table Addresses contient la description de toutes les adresses, celles des lieux et celles des membres du groupe. Le lien entre les deux se fait par un identifieur unique pour chaque table et ces identifieurs permettent d'associer un lieu et son adresse.

La mise à jour des données concernant un lieu se fait de la façon suivante :
1) une requête pour lire les informations
2) affichage dans un formulaire de saisie
3) modifications
4) appui d'un bouton OK
5) requête de mise à jour (dans ma techno actuelle, une requête par table)

Une mise à jour peut prendre un temps de l'ordre de quelques minutes.
Si deux personnes font des mises à jour simultanées, il faut donc éviter qu'elles les fassent sur les lignes correspondantes des deux tables. Cela impose donc un mécanisme de "verrou long"
Si par ailleurs une personne est amenée à interrompre son activité de mise à jour pour une raison quelconque, il faut s'assurer que le verrou ne reste pas actif indéfiniment.

La documentation dont je dispose sur les transactions et verrous en MysSQL ne me semble pas très claire.

Merci de vos conseils

Salut,

a priori il n'y a pas de rapport avec les transactions et verrous en MySQL.

En solution relativement simple je pense, tu dois pouvoir rajouter une colonne "dernière modification" qui va contenir le timestamp de la dernière modification.
Si 2 utilisateurs veulent modifier un même élément en même temps, le premier qui va valider entraînera une modification de cette valeur et du coup le 2e aura un timestamp qui sera plus ancienne que la nouvelle valeur et cela te permettra de voir qu'il y a eu une modification entre temps.

Je ne sais pas si c'est super claire mais en gros tu compare le timestamp que tu leur donnes au moment où ils visualisent la donnée et le timestamp de dernière modification. Si le timestamp de dernière modification est plus récent c'est qu'il y a eu une MAJ entre temps et que l'on risque d'écraser des modifications de l'autre utilisateur.

(Pour éviter d'avoir de la perte on peut aussi "historiser" les modifications en gardant des versions différentes à chaque timestamp, ça permet d'invalider des modifications en lot si un utilisateurs commence à faire n'importe quoi du jour au lendemain en mode j'efface tout)

Bonjour,

L'idée générale de se dire que quand tu arrives sur le formulaire, tu bloques tous les autres jusqu'à ce que tu aies terminé, c'est une mauvaise idée.
D'autant plus que sur le web, tu n'as pas de moyen forcément hyper fiable de détecter que l'utilisateur a quitté le site au milieu de l'opération, autrement que par des timeout plus ou moins longs.

Le mieux serait de faire ce qu'on appelle de l'optimistic locking.

Le principe est assez simple: dans la base de donnée, tu as une colonne habituellement appelée version, que tu incrémentes à chaque modification.
Au début de la session de modification, tu regardes la version.

Au moment où le serveur reçoit les données à mettre à jour du client, si le numéro de version ne correspond plus, c'est que quelqu'un d'autre de plus rapide a fait des modifications entre temps.
Dans ce cas, tu préviens l'utilisateur et tu mets à jour les données affichées dans le formulaire avec ce qu'a modifié l'autre utilisateur. Tu peux, évidemment, mettre spécialement en évidence les données conflictuelles.