La gestion de lock et les transactions [Résolu]

[giviz]

Re Bonjour!

J'ai des tables dans ma base de données (non, sans blagues!!) et plusieurs utilisateurs qui vont les exploiter en meme temps.

Je me retrouve donc avec le problème des accès concurrents avec tous ce que ca implique.

Actuellement j'utilise des locks fixés par le code d'exploitation (php) sur chaque tuples.
C'est à dire que si un utilisateur charge des données en édition je place un lock avec une date, son id et plus personne ne peut charger ces meme données en édition, sauf si le lock à expiré.

Seulement si ca fonctionne bien à petite échelle (mes tests quoi), j'ai cru comprendre que ca posait problème à plus grande echelle et qu'il fallait mieux utiliser les transactions.

Seulement les transactions permettent-elles de s'affranchir complètement de ce problème ?

Je veux simplement que si des données (correspondante à une fiche dans l'application) sont chargées en écriture par un utilisateur, alors les autres ne utilisateurs ne pourront les accéder qu'en lecture.

Si vous pouvez me faire part de vos lumières là dessus

[ego]

Ta solution est ce que l'on appelle le lock pessimiste.
C'est effectivement très très pénalisant en général.
Tu as donc plusieurs solutions :

- Lock optimiste
Dans ce cas, pas de lock en fait. Seulement, quand tu enregistres (modifies) un tuple chargé précédemment, sans lock donc, tu vérifies que personne n'a modifié le tuple depuis que tu l'as lu. Pour faire cela tu peux utiliser par exemple une colonne particulière (nommée par exemple 'version') incrémentée à chaque modification du tuple. Donc résumons cette histoire : quand tu charges le tuple, tu lis entre autre la colonne 'version' (disons que sa valeur est égale à 15 au moment où tu lis). Tu conserves cette information. Quand tu écris le tuple, tu fais un "INSERT INTO ... VALUES (.....,version=16) WHERE version = 15". Si au moment de cet insert, il se trouve que quelqu'un d'autre a fait la même chose avant toi, le numéro de version aura été incrémenté et ne faudra donc plus 15. Ton insert plantera. Dans le cas, peut être 90% des cas, où une seule personne modifie une donnée particulière, le plantage de l'insert ne se produira pas.

- Si tu as du ORACLE, tu peux aussi décider d'utiliser la clause SELECT FOR UPDATE quand tu lis avec intention d'écrire. Dans ce cas, les lecteurs peuvent lire mais toi seul aura le droit d'écrire.

Voila qq idées

[giviz]

Ce système de version me semble etre une bonne piste. Les données vont etre lues dans 90% des cas et modifiées occasionnelement (10% des cas). Les modifications seront très partielles et donc très rapides.

Par contre, admettons que 2 personne lisent la version 15 en meme temps puis tente de la modifier. Elles valident en meme temps.

1) Le sgbd traite une requete à la fois, donc le premier validera ces modifs et le second obtiendra un message d'erreur.
2) Il va y avoir un conflit.

Il se passe quoi ?

Je ne possède pas Oracle, j'utilise Postgresql.

Merci pour ta réponse!

[ego]

Tu auras toujours un gars qui fait la mise à jour avant l'autre car le sgbd gère cela. Donc le second se fera jeter. Il faudra le lui dire de manière explicite

[giviz]

oki, ben ca me parrait nikel alors comme solution, bien plus que le lock, et c'est bien plus simple a gérer!

Merci beaucoup pour ton aide