Шаблон активной записи с оптимистичной блокировкой - читать перед обновлением или сохранить версию в приложении?

Question

Я пытаюсь реализовать шаблон активной записи с использованием Java / JDBC и MySQL вместе с оптимистической блокировкой для обработки параллелизма.

Теперь у меня есть поле 'version_number' для всех записей в таблице, которое увеличиваетсяпосле каждого обновления.

Кажется, что есть стратегии 2 для реализации этого:

1. Приложение, когда оно запрашивает данные, оно также сохраняет соответствующий номер версии каждого из объектов.(т.е. запись).При обновлении номер версии «отправляется» на уровень данных, который используется в запросе UPDATE ... SET ... WHERE для оптимистической блокировки
2. Приложение НЕ сохраняет номер версии, а тольконекоторые части объекта (в отличие от целой строки данных).Чтобы оптимистическая блокировка была успешной, слой данных (активная запись) должен сначала получить «строку» из БД, получить номер версии, а затем запустить тот же запрос UPDATE ... SET ... WHERE для обновления записи.

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

Вопрос в следующем: по замыслу,какой подход лучше ?Это нормально / безопасно / правильно, чтобы все данные, включая номер версии, были сохранены в интерфейсе веб-приложения (Javascript / HTML)?Или лучше оценить производительность чтения перед обновлением?

Есть ли «правильный» способ реализовать этот дизайн?Я не уверен, как нынешние реализации активной записи справляются с этим (Ruby, Play, ActiveJDBC и т. Д.). Если я собираюсь реализовать это в «сыром» виде в JDBC, каково правильное проектное решение в этом случае?

Answer 1

ActiveJDBC реализует версию 1. С версией 2 вы можете ввести условия гонки

Answer 2

Это не вопрос производительности или безопасности, оба подхода функционально различны и достигают разных целей.

При первом подходе вы оптимистично блокируете строку на все время «обдумывания» пользователя.Если пользователь 1 загружает экран, то пользователь 2 вносит изменения, изменения пользователя 1 не будут выполнены, и они увидят ошибку, на которую они смотрели устаревшие данные.

При втором подходе вы защищаете только от чередованияпишет между конкурирующими потоками запросов.Пользователь 1 может загрузить страницу, затем Пользователь 2 вносит изменения, а затем, когда Пользователь 1 нажимает кнопку «Отправить», его изменения пройдут и сгорят изменения Пользователя 2.Пользователь 1, возможно, принял решение, основываясь на устаревшей информации, и никогда не узнает.

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