Исключение OptimisticLockException в веб-приложениях JEE JSF с использованием JPA, когда в одном представлении возможны множественные коммиты - PullRequest
0 голосов
/ 28 апреля 2020

Работа с JEE и JPA с использованием блокировки Optimisti c с помощью @Version в веб-приложении - это рекомендуемый подход для работы с обновлениями (entityManager # merge), если один и тот же пользователь может сделать несколько коммитов из разных наборов объекты-сущности в одном и том же представлении, включая обновление одного и того же объекта-сущности более одного раза?

Проблема, являющаяся entityManager # merge, не обновляет номер версии в полученном им объекте памяти, а скорее возвращает новый объект, который должен будет использоваться в будущем при повторном слиянии. Это означает, что если в памяти есть сложные отношения, все должны быть обновлены с этим новым объектом. Иначе, в следующий раз при попытке объединения из того же представления будет выдано исключение OptimisticLockException.

Вместо того, чтобы проходить через модель представления и обновлять каждый экземпляр объединенного объекта (который открывает дверь к риск ошибок во время выполнения), один из вариантов будет заключаться в том, чтобы не допустить частичной работы в представлении, а затем всегда перестраивать модель представления после каждого обновления. Это кажется довольно примитивным и неэффективным. Хотите знать, если есть какие-либо другие рекомендуемые подходы. Спасибо!

Вот пример сценария:

Пользователь "Менеджер" имеет список "Сотрудники" в своем веб-представлении. «Менеджер» выбирает «Сотрудника», меняет номер телефона и сохраняет. Менеджер понимает, что у нее неправильный номер телефона, исправляет его и снова сохраняет в том же представлении (JSF) или веб-сеансе.

В веб-представлении содержался список сотрудников, который необходим для выбора. После первого обновления, без повторного извлечения этого списка из БД или обновления списка в памяти, номер новой версии сущности не будет распространяться на представление, вызывающее исключительную ситуацию OptimisticLockException при втором сохранении. Есть ли другой вариант, кроме повторного получения списка после 1-го слияния, обновления в памяти после 1-го слияния или поиска памяти перед каждым слиянием слияния в найденный объект, а затем фиксации?

...