Мы работаем над успокаивающим приложением, имеющим функцию «доски». Однажды я задал соответствующий вопрос: Есть ли здесь проблема параллелизма? Как это проверить во время разработки?
Сначала мы решили реализовать основную функциональность без параллелизма только потому, что приложение было в значительной степени незнакомым, и нам пришлось сгладить риски реализации. Поскольку я хорошо осведомлен о концепциях / проблемах параллелизма, я чувствовал, что возможно было бы отложить код управления параллелизмом / конфликтом до наилучшего возможного времени. Кажется, так было до сих пор:)
На доске несколько членов команды могут создавать / читать / обновлять / удалять записи. Конфликты, которые могут возникать в первую очередь, связаны с обновлением и удалением (немного устаревшее чтение считается нормальным, мы получаем периодические обновления)
Сценарий: Каждая запись , которая возвращается, имеет идентификатор, а также последнюю метку времени, установленную MySQL NOW () при первом создании записи.
Сценарий конфликта:
- Непосредственно перед обновлением проверьте, является ли временная метка действительной (или если строка вообще существует). По существу, запрос
select * from ... where... сопровождается проверкой временной метки и обновляет, если то же самое еще «объединить» (то есть просто добавить к текущим данным с помощью ------- КОНФЛИКТ / ОБЪЕДИНЕННЫЙ ------- как разделитель)
Это, похоже, единственный конфликтный сценарий (кто-нибудь может заметить что-то еще, что я могу пропустить?)
Итак, вопрос в том, как на самом деле реализовать эту проверку параллелизма / конфликта? Сценарий должен быть атомарным, то есть проверить, существует ли значение / или оно одинаково, а затем обновить. Создание транзакции - путь? Я не уверен, что если просто выполнить транзакцию Spring и запустить 2 запроса (один для выбора и другой для обновления), то есть или есть синтаксис SQL, который мог бы помочь мне с этим требованием атомарности.
У меня вопрос "как это сделать"? Я читал о SELECT ... FOR ... UPDATE, но не понимаю, как это работает, и при этом я не понимаю, как SELECT ... LOCK IN SHARE MODE мог / мог бы решить проблему.
Любые идеи / указатели были бы очень полезны :) Использование Restlet / Spring-Jdbc / MySql