Я пытаюсь реализовать активный шаблон записи с использованием Java/JDBC и MySQL, а также оптимистичную блокировку для обработки параллелизма.Активный шаблон записи с оптимистичной блокировкой - прочитайте перед обновлением и сохраните версию в приложении?
Теперь у меня есть поле «version_number» для всех записей в таблице, которые увеличиваются после каждого обновления.
Там кажется 2 стратегии для реализации этого:
- Приложения, когда он запрашивает данные, которые он также хранит соответствующий номер версии каждый из объектов (т.е. записи). При обновлении номер версии «отправляется вниз» на уровень данных, который используется в UPDATE ... SET ... WHERE запрос для оптимистической блокировки
- Приложение НЕ хранит номер версии, но только некоторые части объект (в отличие от целой строки данных). Чтобы оптимистичная блокировка была успешной, для слоя данных (активной записи) потребуется сначала извлечь «строку» из БД, получить номер версии и затем запустить тот же UPDATE ... SET ... WHERE запрос для обновления записи.
В первом есть «первая выборка», а затем обновление. В последнем случае у вас есть «первая выборка», но также a fetch перед обновление.
Вопрос в следующем: по дизайну, который лучше подходит? Все в порядке/безопасно/правильно, чтобы все данные, включая номер версии, были сохранены в интерфейсе веб-приложения (Javascript/HTML)? Или лучше взять удар производительности чтения перед обновлением?
Есть ли «правильный путь» для реализации этого дизайна? Я не уверен, как текущие реализации активной записи справляются с этим (Ruby, Play, ActiveJDBC и т. Д.). Если я должен реализовать это «raw» в JDBC, то в этом случае правильное дизайнерское решение?
Я думаю, что есть путаница здесь - я не запираю строку за все время думает, что и не произойдет потерянное обновление! Я просто не сделал явного факта, что я бы выбрал исключение в случае, если обновление не удалось и сообщит пользователю! Я не уверен, что любой из двух сценариев, которые вы упомянули, даже произойдет? – PhD
В сценарии 1 вы оптимистично блокируете строку для размышления.Вы знаете, что такое номер версии, когда пользователь начал думать, и вы убедитесь, что это то же самое, когда они сделаны. В сценарии 2 вы проверяете номер версии только в конце, когда они отправляются. Это может отличаться от того, когда они начали думать, следовательно, потеряли обновление. – Affe
tl; dr option 1 - правильный способ сделать «нормальную» оптимистичную блокировку. вариант 2 приводит к ситуации параллелизма с последними в выигрышах и действительно проверяет только потоки потоков на сервере, а не пользовательские мыслительные чередования. – Affe