11.4. Verouillage pessimiste

It is not intended that users spend much time worrying about locking strategies. It's usually enough to specify an isolation level for the JDBC connections and then simply let the database do all the work. However, advanced users may sometimes wish to obtain exclusive pessimistic locks, or re-obtain locks at the start of a new transaction.

Hibernate utilisera toujours le mécanisme de verrouillage de la base de données et ne verrouillera jamais les objets en mémoire!

La classe LockMode définit les différents niveaux de verrouillage pouvant être obtenus par Hibernate. Le verrouillage est obtenu par les mécanismes suivants:

Les niveaux de verrouillage peuvent être explicitement obtenus de l'une des manières suivantes:

Si Session.load() est appelé avec le paramètre de niveau de verouillage UPGRADE ou UPGRADE_NOWAIT et que l'objet demandé n'est pas présent dans la session, celui-ci sera chargé à l'aide d'une requête SELECT ... FOR UPDATE . Si la méthode load() est appelée pour un objet déjà en session avec un verrouillage moindre que celui demandé, Hibernate appellera la méthode lock() pour cet objet.

Session.lock() effectue une vérification de version si le niveau de verrouillage est READ , UPGRADE ou UPGRADE_NOWAIT . (Dans le cas des niveaux UPGRADE ou UPGRADE_NOWAIT , une requête SELECT ... FOR UPDATE sera utilisée.)

Si une base de données ne supporte pas le niveau de verrouillage demandé, Hibernate utilisera un niveau alternatif convenable au lieux de lancer une exception. Ceci assurera la portabilité de votre application.