По материалам статьи Craig Freedman: Repeatable Read Isolation Level

В двух предыдущих статьях (1, 2) было продемонстрировано как запросы с уровнем изоляции «read committed» могли порождать неожиданные результаты. Это становилось возможным из-за выполняющихся в одно и то же время изменений затронутых запросом строк. Чтобы недопустить подобных неожиданностей (но не всех), следует использовать для выборки уровень изоляции «repeatable read». В этой статье мы как раз и рассмотрим как одновременные изменения ведут себя с уровнем изоляции «repeatable read» (повторяемое чтение).
В отличие от просмотра с «read committed», просмотр с «repeatable read» удерживает блокировки каждой затронутой строки до окончания транзакции. На всём протяжении транзакции заблокированными могут оказаться даже некоторые строки, которые не соответствуют выборке в результате запроса. Такое блокирование гарантирует, что затронутые запросом строки не будут изменены или удалены в параллельном сеансе, пока текущая транзакция не будет завершена (независимо от того, будет ли она зафиксирована или произойдёт её откат). Эти блокировки не защищают от изменения или удаления те строки, которые еще не были охвачены просмотром, и не препятствуют вставке новых строк межу уже заблокированными строками.

Читать далее

https://habr.com/ru/post/662407/?utm_source=habrahabr&utm_medium=rss&utm_campaign=662407