Какой-то частный случай оптимистической блокировки Eclipselink JPA

Question

Я начинаю с оптимистической блокировки JPA. Мне нужно выполнить следующий сценарий.

Пользователь не нужен Просьба для рассмотрения. Этот запрос имеет статус . Будучи просто поставленным, он имеет статус 'new'. Затем несколько служб могут наблюдать этот запрос и обслуживать его, изменяя его статус. (Статус может быть, например, «обработка», * 'put_back' *, 'finished'). Таким образом, я использую оптимистичную блокировку, чтобы гарантировать, что только один сервис в настоящее время работает с запросом. Поэтому, когда какая-то другая служба пытается поставить статус запроса с «нового» на «обработку», он даст мне OptimisticLockingException, и я сообщу услугу с чем-то вроде этого. «Текущее состояние запроса изменилось, пожалуйста, обновите свой запрос список". Это звучит нормально. Таким образом, это ситуация, когда две службы пытаются одновременно обрабатывать один и тот же запрос.

Но мое особое требование заключается в том, что в любой период времени пользователь может отменить запрос, установив свой статус на «аннулирован». Поэтому в этом случае я могу получить исключение OptimisticLockingException. Но мне это не нужно. Таким образом, запрос не будет отменен. Здесь я хочу поставить статус «отменен» независимо от того, был ли он изменен кем-то другим. Думаю, я не должен просить пользователя снова отменить его запрос.

Мой вопрос:: Как я могу справиться с этой ситуацией с EclipseLink 2.4.1 Я использую для настойчивости.

Примечание: Я новичок в Оптимистическом блокировании в JPA, поэтому могу что-то пропустить, пожалуйста, исправьте, если это так.

Answer 1

Я бы справился с этим в вашем приложении. Если вы получаете исключение блокировки в операции cancelRequest(), просто перехватите Exception и повторите транзакцию до ее фиксации.

Вы также можете использовать запрос обновления JPQL, так как он не проверяет версию блокировки.