простой вопрос дизайна о оптимистичной блокировке весной / jpa / hibernate

Question

У меня есть объект GeneralKnowledgeTest, и он содержит много полей статистики (оценок, рейтингов, откликов, рейтингов ...), которые обновляются каждый раз, когда пользователь проходит этот тест (takeTest () -> метод транзакций).

Может случиться, что многие пользователи будут проходить один и тот же тест в одно и то же время, поэтому я подумывал о реализации оптимистической блокировки (@version) и перехватчика, который повторяет метод takeTest в случае, если исключение оптимистической блокировки

Итак, внутри метода takeTest я всегда получаю свежий экземпляр GeneralKnowledgeTest, например, entityManager.find (testId) , затем обновляю его поля статистики.В случае, если выдается оптимистическое исключение, перехватчик просто повторяет метод takeTest до его успешного завершения.

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

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

Answer 1

Это звучит как правильный подход:

Hibernate проверяет версии экземпляров во время сброса, выдает исключение при обнаружении одновременной модификации.Разработчик должен поймать и обработать это исключение.Общие параметры - это возможность для пользователя объединить изменения или перезапустить бизнес-разговор с нестарелыми данными.

Вы также можете посмотреть, как установить для параметра IsolationLevel значение SERIALIZED или заблокировать строку таблицы.

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

Answer 2

Я полагаю, что эти статистические данные обновляются только в конце теста, и тестам требуется разумное количество времени для запуска, поэтому это уменьшит вероятность сбоя оптимистичной блокировки.Кроме того, есть ли вероятность того, что пользователи завершат тестирование в пакетах, например, в результате запуска теста в установленное время?Это увеличит вероятность сбоя блокировки.

Если пропускная способность такова, что параллельные обновления все еще вероятны, то вам лучше было бы агрегировать статистику в памяти (потокобезопасным способом) и периодически записывать ихв базу данных.