Modification simultanée d'un même enregistrement [Résolu]

[Arnaud57]

Bonjour

Je souhaiterai savoir quelle est la méthode pour empêcher la modification simultanée d'un enregistrement dans une table MySQL. En pratique, le cas se pose lorsqu'un utilisateur va vouloir modifier un enregistrement pendant qu'un autre utilisateur est en train de le modifier. Les clé étant les même, le dernier qui va faire la modification sera le gagnant....

J'aimerai verrouiller la table uniquement en lecture mais si on verrouille la table et que l'utilisateur qui le navigateur sans avoir faire la requête UPDATE et donc le UNLOCK, la table serait alors VEROUILLER totalement....

Merci d'avance pour votre aide.

Arnaud

[qi130]

Il existe au moins 2 techniques pour pallier ce problème. L'utilisation de l'une ou l'autre dépend de l'architecture technique de ton appli...

La 1ère consiste à utiliser un timestamp.
Cette technique est à employer si ton architecture est asynchrone (transactionnelle): l'utilisateur acquiert un enreg, le modifie, demande la sauvegarde. Là, on relie l'enreg en le lockant, on compare le timestamp relu avec celui acquis en début de transaction.
Si ok on écrit avec un nouveau timestamp et on délocke, si ko msg d'erreur et délockage.
Il faut bien sûr que la table héberge une colonne réservée au timestamp.
En général, ce timestamp est de format

Code :

AAAAMMJJ-HHMMSS

(avec des séparateurs si on veut, si le SGBD ne connait pas le type timestamp). Parfois le timestamp peut aller jusqu'aux millisecondes.

La 2nde consiste à locker la ligne (au mieux) ou la page (au pire ) [selon la richesse technique du SGBD => éviter les SGBD qui lockent au niveau table] au moment de l'acquisition pour modif. Evidemment ça bloque les autres utilisateurs sur cette ligne ou cette page (d'où l'importance de bien tailler la taille de la page sous certains SGBD: petites lignes + grosses pages= proba importante de bloquer qq'un d'autre)

En espérant avoir éclairé ta lanterne...

[Arnaud57]

Bonjour,

merci pour cette réponse très intéressante.

La première solution me semble plus adaptée que la seconde mais je n'ai pas tout compris à vrai dire.

Si on pouvait juste décrire un cas d'utilisation et si tu pouvais me dire si j'ai bien capté le truc.

- L'utilisateur 1 ouvra la page de modification de l'enregistrement.
>>>On modifie le timestand dans l'enregistrement (en faisant un update avec les même valeur je suppose)
- Ensuite l'utilisateur saisie les valeurs des nouveaux champs dans sa page php

Si un autre utilisateur souhaite modifier le même enregistrement, il ouvre la page et modifie lui aussi le timestand.

- Au moment de l'insertion du premier utilisateur, on LOCK la table, compare le timestand saisie au départ et le timestand de l'enregistrement à modifier et si ce sont les même alors on modifie sinon on rejette la modification et dans tous les cas on UNLOCK juste après.

- L'autre utilisateur enregistre alors et ça marche.

Du coup c'est le dernier utilisateur qui à le droit à l'enregistrement.

Merci beaucoup.

Si c'est bien ça, c'est pas mal

MERCI!!!

[gnolfy]

Moi pas du tout eclairer

Lanterne completement eteinte

surtout a partir de "si ok" keski est ok ?

[qi130]

Envoyé par gnolfy

Moi pas du tout eclairer

Lanterne completement eteinte

surtout a partir de "si ok" keski est ok ?

la comparaison !
reformulation: si à la suite de cette comparaison, les timestamps sont identiques (=ok)...

[qi130]

Envoyé par Arnaud57

Bonjour,

merci pour cette réponse très intéressante.

La première solution me semble plus adaptée que la seconde mais je n'ai pas tout compris à vrai dire.

Si on pouvait juste décrire un cas d'utilisation et si tu pouvais me dire si j'ai bien capté le truc.

- L'utilisateur 1 ouvra la page de modification de l'enregistrement.
>>>On modifie le timestand dans l'enregistrement (en faisant un update avec les même valeur je suppose)
- Ensuite l'utilisateur saisie les valeurs des nouveaux champs dans sa page php

Si un autre utilisateur souhaite modifier le même enregistrement, il ouvre la page et modifie lui aussi le timestand.

- Au moment de l'insertion du premier utilisateur, on LOCK la table, compare le timestand saisie au départ et le timestand de l'enregistrement à modifier et si ce sont les même alors on modifie sinon on rejette la modification et dans tous les cas on UNLOCK juste après.

- L'autre utilisateur enregistre alors et ça marche.

Du coup c'est le dernier utilisateur qui à le droit à l'enregistrement.

Merci beaucoup.

Si c'est bien ça, c'est pas mal

MERCI!!!

Alors...
1 utilisateur veut modifier une fiche: plein de données et 1 timestamp valant ts1 (pour faire cours). le ts1 est en "réserve" quelque part en mémoire du PC de cet utilisateur. il fait Ok pour valider ses modifs et réécrire en BdD:
1/ relire la ligne en BdD (en fait seul le timestamp est nécessaire) en lockant
2/ comparer ce timestamp avec la valeur en mémoire
2.a/ si le timestamp vaut toujours ts1 => ok pour l'update avec nouvelle valeur du timestamp (=ts2), puis délocke
2.b/ si valeurs <> (ts1 vs. ts2) on délocke

Rappel, effectuer le lock sur le niveau le plus fin possible suivant le SGBD:
1/ la ligne si possible
2/ la page en 2ème choix
3/ la table si on peut pas faire autrement ( )