Изучаем Java EE 7

em.lock(book, LockModeType.OPTIMISTIC);

book.raisePriceByTwoDollars();

При оптимистической блокировке LockModeType, передаваемый вами в качестве параметра, может принимать два значения: OPTIMISTIC и OPTIMISTIC_FORCE_INCREMENT (или соответственно READ и WRITE, однако эти значения устарели). Единственное отличие заключается в том, что OPTIMISTIC_FORCE_INCREMENT форсирует обновление (инкрементирование) значения столбца version, связанного с сущностью.

При работе с приложениями настоятельно рекомендуется делать возможной оптимистическую блокировку всех сущностей, к которым разрешен конкурентный доступ. Неиспользование механизма блокировки может привести к несогласованному состоянию сущности, потерянным обновлениям и другим нарушениям состояния. Оптимистическая блокировка — полезная оптимизация производительности, освобождающая от работы, которую в ином случае потребовалось бы выполнить базе данных. Она представляет собой альтернативу пессимистической блокировке, которая подразумевает применение низкоуровневой блокировки базы данных.

Пессимистическая блокировка

Пессимистическая блокировка основана на предположении, противоположном тому, которое действует для оптимистической блокировки, так как пессимистическая блокировка быстро применяется к сущности до начала операций с ней. Это очень ограничивает ресурсы и приводит к значительному снижению производительности, так как блокировка базы данных поддерживается с использованием SQL-оператора SELECT… FOR UPDATE для чтения данных.

Базы данных обычно предлагают службу для обеспечения пессимистической блокировки. Такая служба позволяет менеджеру сущностей блокировать строку таблицы для предотвращения обновления этой же строки другим потоком. Это эффективный механизм, который гарантирует, что два клиента не смогут одновременно модифицировать одну и ту же строку, однако он требует проведения затратных низкоуровневых проверок в базе данных. Результатом транзакций, которые привели бы к нарушению этого ограничения, стало бы генерирование исключения PessimisticLockException, а эти транзакции были бы помечены как подлежащие откату.

Оптимистическая блокировка целесообразна, когда вы сталкиваетесь с умеренным соперничеством между конкурирующими транзакциями. Однако в некоторых приложениях с более высокой степенью риска соперничества уместнее может оказаться пессимистическая блокировка, поскольку блокировка базы данных применяется незамедлительно в противоположность сбоям оптимистических транзакций, случающимся позднее. Например, во времена экономических кризисов на фондовые рынки поступает огромное количество поручений на продажу. Если одновременно 100 миллионам американцев потребуется продать ценные бумаги, то системе придется прибегнуть к пессимистическим блокировкам для обеспечения согласованности данных. Следует отметить, что в настоящее время рынок настроен довольно пессимистично, а не оптимистично, однако это никак не связано с JPA.

Пессимистическая блокировка может применяться к сущностям, которые не включают аннотированный атрибут @Version.

Жизненный цикл сущности

Вам уже известно большинство секретов сущностей, поэтому взглянем на их жизненный цикл. Созданный (с использованием оператора new) экземпляр сущности виртуальная машина Java рассматривает как простой Java-объект (то есть отсоединенный), который может быть использован приложением в качестве простого объекта. Затем, когда менеджер сущностей обеспечивает постоянство этой сущности, считается, что она находится под управлением. Когда сущность будет находиться под управлением, менеджер сущностей автоматически синхронизирует значения ее атрибутов с основной базой данных (например, если вы измените значение атрибута с помощью метода set, а сущность при этом будет находиться под управлением, то это новое значение окажется автоматически синхронизировано с базой данных).

Чтобы лучше понять этот процесс, взгляните на рис. 6.6, где приведена UML-диаграмма состояний. На ней показаны переходы между всеми состояниями сущности Customer.

Рис. 6.6. Жизненный цикл сущности