search

ovesco / intranetBS

le netBS
MIT License
7 stars 0 forks source link

Concurrence de version lors du persiste via doctrine (ou comment éviter les problèmes de version) #63

Open nuffer opened 9 years ago

nuffer commented 9 years ago

Imaginons que deux clients edit l'objet x et font des modifs puis poste le formulaire avec un leger petite temps de décalage. Est-ce que le premier est écrasé par le deuxieme?

C'est con mais je crois qu'on en avait deja discuter...qu'est ce qu'on peut faire la contre?

loicmonney commented 9 years ago

Il peut effectivement y avoir des écrasements sans que les utilisateurs s'en rendent compte (possible perte d'information, incohérences, ...).

Pour ce protéger contre cela, vous pouvez mettre des verrous: http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html#locking-support

nuffer commented 9 years ago

Genial merci bcp! ca a l'aire d'être exactement ce qu'il nous faut!

mullerch commented 9 years ago

Le plus dangereux est si deux actions se font dans la BDD en concurrence car ça peux flinguer la cohérence de la BDD. On devrait pas avoir ce problème vu que Doctrine gère probablement ça avec des transactions (a vérifier).

Par contre on a en effet ce problème d'écrasement des données, mais qui est fortement réduit par le fait que nos formulaire s'envoient par champs, et pas par object complet. Donc quand on met à jour un attribut, il n'y a que lui qui va changer, les autres champs sont récupérés de la BDD au moment de l'envoi ce qui réduit la fenêtre de concurrence. Donc au pire, on écrase une donnée qui vient d'être mise à jour, avec une autre qui vient aussi d'être mise à jour. Au mieux on peut espérer que la modif était identique, au pire les deux informations ont le même niveau de pertinence donc peuvent théoriquement s'écraser sans problème.

Le problème est plus important quand un utilisateur effectue des actions sur un élément qui a été supprimé par exemple. Cela dit je pense qu'il y a peu de chances que ce cas de figure arrive vu le nombre d'utilisateurs. Et au pire, c'est une erreur qui est renvoyée.

nuffer commented 9 years ago

Ouai je suis d'accord que c'est pas très fréquent. Mais ca vaut peut-être la peine de mettre en place le champ @version de doctrine comme ca on leve une exeption quand cela ce produit...

loicmonney commented 9 years ago

On devrait pas avoir ce problème vu que Doctrine gère probablement ça avec des transactions (a vérifier).

Doctrine utilise bien des transactions comme illustré dans la documentation: Doctrine 2 already takes care of proper transaction demarcation for you: All the write operations (INSERT/UPDATE/DELETE) are queued until EntityManager#flush() is invoked which wraps all of these changes in a single transaction [1]. Comme la base de données utilise InnoDB, le niveau d'isolation des transactions est en REPEATABLE READ [2][3]. Les transactions sont donc sensibles aux phantoms, mais je ne pense pas que cela pause problème car je ne pense pas que vous fassiez plusieurs fois la même lecture sur autre chose qu'une "clé" dans vos actions (je peux donner plus de détails au besoin).

Comme ozwin l'a évoqué le problème qui persiste est bien celui causé entre les transactions:

  1. l'utilisateur A veut modifier un membre > On ouvre une connexion à MySQL > on démarre une transaction > On sélectionne les détails du membre > On affiche le formulaire > la transaction s'arrête, ... > fin du script
  2. l'utilisateur A modifie les détails du membre (qui sait, peut-être qu'il est allé boire un café, qu'il est parti manger entre temps ou alors qu'il a décidé de poursuivre le lendemain?)
  3. l'utilisateur A soumet la requête > on ouvre une connexion à MySQL > on démarre une transaction (problème ici, on est pas certain que les données lues dans la transaction en 1. soient les mêmes) > on fait les modifications (peut-être qu'on écrase autre chose de l'utilisateur B, ou alors les modifications de B sont "perdues" au milieu des versions, ou encore possible que le membre ait été supprimé)
nuffer commented 8 years ago

@ozwin est-ce vraiment important pour la v1...a mon avis pas. Si t'es d'accord, je te laisse enlevé le milestone

mullerch commented 8 years ago

Ce n'est pas une priorité à mon sens. Par contre il faudrait qu'on aie l'historique des données dans la fiche membre, comme ça au pire l'information écrasé reste disponible quelque part.