простой оптимистичный вопрос блокировки в jpa / spring / hibernate

Question

Я пытаюсь реализовать базовый механизм оптимистической блокировки с перехватчиком попыток.

Итак, дело в том, что существует объект Quiz со свойством откликами. В случае, если во время обновления теста возникает исключение оптимистической блокировки, соответствующий метод обновления будет снова вызываться из перехватчика повторных попыток.

Дело в том, что что-то не так, потому что повторный метод каждый раз имеет один и тот же номер версии, и из-за этого он не сможет выполнить транзакцию, несмотря ни на что.

версия: 10

процесс А: начать обновление викторины, версия 10 процесс Б: начать обновление викторины, версия 10 процесс Б: завершить обновление викторины, версия 11 процесс А: оптимистическое исключение выдвинуто подняло тест обновления, повторите процесс A внутри повторного метода версия всегда 10

Что я могу сделать тогда? Он должен автоматически увеличивать версию для успешной транзакции

Answer 1

Мне кажется, что вы хотите обновить тест, даже если кто-то еще обновил его за вашей спиной (что вызывает оптимистическое исключение). Если это так, почему вы включаете оптимистическую регистрацию для этой сущности? Просто удалите поле версии, и оно будет работать даже без повторных попыток.

Если вы действительно хотите сохранить поле версии, измените метод так, чтобы он получал опрос из БД, копирует номер версии только что загруженного теста в ваш отдельный экземпляр, а затем объедините отдельный экземпляр, чтобы скопировать все новые значения к приложенному.

Answer 2

Исключение оптимистической блокировки обрабатывается следующим образом:

Сначала перечитайте запись, получив новый номер версии и обновленные значения полей, которые записала конфликтующая транзакция.

Затем повторно примените вашуоперация, основанная на новых значениях.В вашем случае это просто - увеличение значения не зависит от порядка или коммутативно.Другие операции могут быть непростыми для повторного применения - например, предположим, что обе транзакции пытались переместить ошибку в системе отслеживания проблем из одного состояния рабочего процесса в другое.Этот переход может произойти только один раз, поэтому повторяющаяся транзакция должна будет проверить, что ошибка все еще находится в допустимом состоянии для этого перехода, и в противном случае она выдаст сообщение об ошибке пользователю.

Answer 3

Вы пытаетесь победить оптимистическую блокировку: D, в связи с чем возникает вопрос: вам нужна оптимистическая блокировка?

Единственный разумный способ, которым я вижу повторение без потери предыдущих данных, этообновите объект и затем примените изменения снова ... в любом случае, вы собираетесь переопределить данные, что противоречит идее оптимистических блокировок.

В вашем случае я бы отключил оптимистическую блокировку навсе или поместите счет во вспомогательную таблицу без оптимистической блокировки.