Есть ли способ узнать, когда возникает проблема оптимистического параллелизма в JPA и как ее решить?Как решить оптимистичный случай обновления параллелизма в JPA
Описание проблемы: В моем проекте, когда я хочу обновлять данные в БД, но другой пользователь использовал его. В такой ситуации я хочу получить DB_STATUS или исключение, что означает «Другой пользователь использовал ..». Так что я хочу пропустить обновление БД.
Поле или свойство Version используется поставщиком постоянного обслуживания для выполнения оптимистической блокировки. Он доступен и/или задан поставщиком непрерывности в ходе выполнения операций жизненного цикла экземпляра объекта. Объект автоматически включаются для оптимистической блокировки, если он имеет свойство или поле отображается с Version mapping:
Определить version собственности в вашей организации:
@Version
private long version;
и соответствующее version поля в вашей таблице БД для организация.
Предположим, что вы загрузили объект с идентификатором = 123 и version = 1. По завершении транзакции состояние объекта изменится на состояние detached.
Вы внесли изменения в объект в своем detached состоянии. Вы можете сделать эти изменения постоянными, используя EntityManager.merge(). И как это detached экземпляра, Hibernate будет выпускать обновления SQL, похожее на это:
update ENTITY set ... , VERSION=2 where ID=123 and VERSION=1
Если другая транзакция приложения будет обновила и тот же объект, так как он был загружен, столбец версии не будет содержать значение 1, и строка не будет обновляться. Вы получите OptimisticLockException, и сделка будет маркирована для отката. Вы можете поймать исключение и сообщить Пользователю о устаревших данных.
Операция слияния рассматривает атрибут version при объединении объекта и выдает OptimisticLockException, если обнаружено, что объект, который был объединен, является устаревшей копией объекта-i.e. что объект обновлен с момента отсоединения объекта.