Bonjour à tous !

Je souhaite avoir une petite précision au sujet des 'pessimistic lock'.
Voici un petit code d'example :


Avec les paramètres par défaut, o2 ne vaut pas null.
Or, si l'on précise explicitement que l'on veut 'locker' une instance, on ne devrait plus y avoir accès dans les autres sessions, non ?

Merci d'avance pour vos réactions.
Joël.

Pourquoi o2 devrait il être null?

D'après la javadoc, LockMode.UPGRADE est equivalent à une requete SQL select ... for update.

Tu poses donc un lock, pour que personne ne puisse mettre à jour ton objet o.
Si dans une transaction différente tu essayes de modifier o2, je ne pense pas que tu puisses tant que le verrou ne sera pas supprimé.

Merci pour ta réponse, lauvigne.

Effectivement, o2 peut être initialisé correctement si on part du principe que des données verrouillées peuvent tout de même être accessibles en lecture seule.

Mon problème est que ca ne devrait pas etre le cas chez moi. Des données verrouillées ne peuvent pas être accessibles en lecture. Il faudrait donc que je puisse savoir si un objet est déjà verrouillé dans une autre session.

Par exemple, c'aurait été bien pratique pour moi si, en ajoutant cette ligne au code précédent :

j'obtienne une exception de type org.hibernate.exception.LockAcquisitionException, par exemple (d'ailleurs, en faisant une recherche dans le code, je ne vois nulle part où le constructeur de cette classe est appelé, est-ce normal ?)
Or, suite à mon code, tout se déroule correctement (pas d'exception) et je me retrouve avec 2 instances lockées, ce qui ne me semble pas logique.

Ai-je mal interprété le rôle du lock, ou bien est ce que je ne l'utilise pas convenablement ?

Merci d'avance,
Joël.