д0kХПравильно , оракл читает предыдущую версию.
Если другая сессия закомитится раньше ,
а потом эта сессия изменит закомиченную записть на основании
предыдущей версии, все приплыли.
Есть 2 пользвательский сессии и 3 счета.
нужно с одной счета перекинуть по 10 рублей на 2 других.
остаток на нем 100 рублей
первая читает
100 рублей отнимате 10 и пошет в остаток 90
в это время другая читает предцдущую версию - 100 рублей
и пишет в остаток 90.
Комитится первая комитится вторая .
на счету должно быть 80 рублей , а у нас 90.
что бы избежать этого артефакта остаток
по счету где 100 рублей нужно читать в режиме
select for update в всех сессиях кто планирует менять остатки .
и изменять никак по другому как через where curent of
Обычно АБС немного не так устроены
По каждой фин.транзакции пишутся только обороты по обоим счетам, а остатки вычисляются по требованию или собираютcя ночью во время закрытие опер дня с начислением процентов/комиссий
Если счет консолидированый, тот же коррсчет в центрабанке, то по нему пару млн. документов в день обычная(даже скромная) цифра.
Строка(страница/блок памяти OS) содержащая остаток умерла бы на блокировках/мутексах при такой архитектуре
В стандарте ANSI SQL 4 уровня изоляции и 4 вида аномалий/феноменов:
SERIALIZABLE - блокирует все просканированные строки в процессе выполнения запроса(нет феноменов)
REPEATABLE READ - блокирует все отфетченные в приложение строки(возможен феномен - появление новых строк при повторном чтении)
READ COMMITED - блокирует строку на которой курсор и измененные записи(возможны феномены - появление новых строк и измененные строки при повторном селекте)
READ UNCOMMITED - ничего не блокирует, возможны три феномена access to uncommitted data, non-repeatable reads, and phantom reads, невозможен lost updates потому что он разваливает целостность бд и не допустим в database engines в целом