Hibernate интересные моменты часть 4.

В прошлой статья я рассказал вам о оптимистической блокировке - Hibernate интересные моменты часть 3. В этой статье я постараюсь кратко рассказать о pessimistic locking. В Hibernate, пессимистическая блокировка - реализована блокировками уровня баз данных. То есть при использовании pessimistic locking имеет смысл глянуть прежде всего на то, какая СУБД используется, на основе каких блокировок самой СУБД, могут реализовываться механизмы блокировки Hibernate. И так pessimistic locking случается когда вы считываете данные (Сущность - Entity) и пытаетесь овладеть данными для монопольного владения или изменения Сущности, блокировка  удерживатся пока транзакция в hibrnate сессии не закончится. В Hibernate существует специальный класс LockMode который позволяет нам выбрать тип блокировки. Обычно этот класс используется в следующих методах:

Session.load(Class, id, LockMode);
Session.get(Class, id, LockMode);
Session.lock(Object, LockMode);
Query.setLockMode(alias, LockMode);

И так какие уровни блокировки у нас есть:

 LockMode.NONE - не используются, ни какие блокировки БД на уровне запроса, по умолчанию load() и get() используют LockMode.NONE, если запрашивается объект(Entity) и он существует в любом кеше hibernate, то используется кеш, sql запрос не формируется.

LockMode.READ - блокировка используется обычно для принудительной проверки версионности у detached-объектов - это persistent-объект отсоединенный от сессии. т. е. заставляет hibernate всегда запрашивать данные из БД, даже если есть данные в любом кэше, одним словом происходит игнорирование любого кеша hibernate, что приводит к проверке версионности у detached-объекта. Не используются,  ни какие внутренние блокировки Баз Данных на уровне запроса.

LockMode.UPGRADE - блокировка использует механизм внутренний монопольной блокировки  Баз Данных на уровне запроса - select ... for update, т. е. запрошенная запись (Entity) блокируется для дальнейшего изменения, если запись не может быть заблокирована немедленно, то происходит ожидание освобождения данных.

LockMode.UPGRADE_NOWAIT - блокировка похожа на LockMode.UPGRADE, но только  использует запрос select for update nowait, отличие в том, если запись не может быть заблокирована сразу, то происходит исключение. На моей памяти запрос select for update nowait поддерживает только БД Oracle, соответственно если БД не поддерживает такие запросы, то LockMode.UPGRADE_NOWAIT преобразуется к блокировке LockMode.UPGRADE.

LockMode.FORCE - используется для принудительного увеличения версионного поля в объекте сущности(Entity), да же если в текущей транзакции, не менялось состояние полей у Entity-объекта. 

LockMode.WRITE - случается когда объект сущности(Entity) обновляется (update) или вставляется (inserte), этот уровень блокировки используется только внутренним механизмом hibernate и его использовать в методах запрешено.

На практике я пользовался в основном, только LockMode.UPGRADE и LockMode.FORCE блокировками, но если вы часто используете их, то может луче задуматься и  повысить уровень изоляции транзакции? - о них читайте мою статью - Hibernate интересные моменты часть 2.