Спецификация для уровня изоляции Repeatable-Read определяет, что транзакция с этим IL будет препятствовать тому, чтобы другие транзакции обновляли любые строки, которые эта транзакция прочитала, до тех пор, пока эта транзакция не будет завершена. Таким образом, повторяемое чтение гарантировано.
Рассмотрим следующий порядок операций для двух параллельных транзакций T1 и T2, каждая из которых использует повторяемое чтение IL:
- T1: чтение строки
- T2: чтение строки
- T1: обновление строки
- T2: обновление строки
Я думаю, что обновление на шаге 3 нарушит спецификацию изоляции уровень, так как T2 будет читать другое значение, если он прочитает строку снова. Обратное можно сказать об обновлении на шаге 4.
Итак, какие различные опции доступны для СУБД в целом, чтобы разрешить этот конфликт? Более конкретно, как это обрабатывается в SQL Server 2017+? Приведет ли это к тупику, поскольку ни одна транзакция не может завершить свои операции? Или откатится одна транзакция? Я видел, что потерянные обновления предотвращаются на SQL сервере. Что это означает для разрешения этого конкретного случая c?
Я просмотрел ответы на следующие вопросы: Повторяемая таблица совместимости чтения и блокировки Повторяемая информация чтения - я Понимаете ли вы это правильно? проблема повторного чтения и повторных потерянных обновлений MySQL Уровень изоляции повторяемого чтения и явления Lost Update
И хотя последний спрашивает похожий вопрос, но не включает никакой конкретной c информации о том, как СУБД, которые предотвращают потерянные обновления для txs с этим уровнем изоляции, обрабатывают этот случай.