Discussion :

[superviny]

Bonjour,

Je développe une application webflow pour la gestion d'un stock.

Sur chacune de mes entités j'ai ajouté l'annotation @OptimisticLocking(type = OptimisticLockType.ALL).
Résultat lorsqu'un utilisateur "A" édite un enregistrement en même temps que l'utilisateur "B". Si "B" modifie l'enregistrement, quand "A" fera la même opération, l'exception javax.persistence.OptimisticLockException est levée. Je l'intercepte dans le configuration de mon webflow et affiche un message d'erreur à l'utilisateur.

Jusque là, c'est parfait!

Voici donc le scénario qui me pose problème. L'utilisateur "A" édite un enregistrement en même temps que "B". "B" le modifie et le sauve. "A" ne modifie rien mais clique sur le bouton "SAUVÉ" donc je persiste l'entité qu'il a chargé en session au moment de l'édition mais qui ne contient plus les données qui sont réellement dans la base de données puisqu'entre temps "B" les a modifiées. Et là aucune levée d'exception...

Est-ce que qqu'un pourrait m'éclairer sur ce comportement et/ou m'aider à le contrecarrer?

Merci

[jeffray03]

Salut

tu pourras gerer cela avec les versions,
si la version est plus ancienne que celle actuellement dans la base de données, alors pas de sauvegarde.

Eric

[superviny]

Salut

tu pourras gerer cela avec les versions,
si la version est plus ancienne que celle actuellement dans la base de données, alors pas de sauvegarde.

Eric

Bonjour Eric,

Merci pour ta réponse.

Je présume que tu parles de l'annotation @VERSION mais je n'ai pas utilisé cette technique, j'ai utilisé:
@OptimisticLocking(type = OptimisticLockType.ALL)
@DynamicUpdate(value = true)

Selon ce que j'ai compris ça ne change pas grand chose:
- Avec le champ version, Hibernate va générer une requête SQL du style "update set .... where [champ version]=[la valeur lue au moment de l'édition]", si cette requête renvoi "0 record affected" alors c'est que le champ version a changé de valeur, dès lors levée de l'exception "javax.persistence.OptimisticLockException"

- Dans mon cas, avec OptimisticLockType.ALL, la requête SQL sera "update set ... where [champ1]=[valeur du champ1 au moment de l'édition], [champ2]=[valeur du champ 2 au moment de l'édition], ...". Ensuite idem si la requête renvoi "0 record affected" alors levée de l'exception.

Je pense donc que ce qui se passe c'est que lorsque je persist mon entité, Hibernate ne voit aucune différence entre l'entité chargée en session au moment de l'édition et les valeurs stockées dans l'entité au moment où je la persist. Dès lors Hibernate ne génère aucune requête sql et donc aucune levée d'exception.... Si mon analyse est correcte, l'utilisation de @VERSION ne changera rien. Le comportement sera le même...

Je trouve cependant que le dernier a avoir appuyer sur "SAUVÉ" devrait être averti que les informations qu'il a sauvé ne sont pas celles qui sont dans la base de données...

[jeffray03]

Ah ok je te comprend,
oui oui, cela marcherais aussi, la au moment de modifier les donnees dans la table, il y aura un verification sur tout les mattributs de l´entite qu´il mettra dans la Where-Clause.
par exemple, si tu as une table Produit(Id, nom, model, prix) et que tu modifies la valeur du champ nom,
alors au moment de l´insert avec optimistic-lock=”all” attribute et dynamic-update=”true” ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
update
   Produit
  set
       nom=?
       where
            id=?
            and nnom=?
            and model=?
            and prix=?

Eric

[superviny]

OK merci Eric...

Ma question reste donc en suspend... Est-ce normal que si je persiste une entité dont les données qu'elle contient sont identiques aux données chargées en session, aucune exception ne soit déclenchée ou est-ce que qques choses m'échappe ou ai-je fait une erreur qques part... ??

[jeffray03]

salut,
voici un exemple:
tiré de : https://blogs.oracle.com/carolmcdona...oncurrency_and

donc la premiere personne a sauvegarder changera le numero de la version, et la deuxieme personne ne pourra plus faire le changement car il ne trouvera plus la version dans la base de données et une exception sera levée.

Eric