NETClientд0kХВозмите любой блокировочник , поставьте режим грязного чтения
ваш результат будет не хуже.Как?! Но ведь согласованное чтение закоммиченных данных и грязное чтение - не одно и то же.
А абзац про консистентность - прости, не осилил.

согласованное относительно одной пользовательской сессии , не значит что
изменения сделанные на основании этого одного согласованного
чтения будут согласованы с ожидаемым поведением бизнес логики при изменении данных.
Для того что бы реально согласовать чтения и изменения
оракл придумал неявный рестарт транзакций , что бы не отсупать от своей логики
согласованного чтения.

NETClientПопытаюсь по порядку.
д0kХБлокировчник вешает блокировку на всю глубину транзакции
и даже дальше если ему это сказал программист.Не представляю, как с этим работать. Видимо потому что не сталкивался.

д0kХОракл по умолчанию никак не гарантирует согласованность
данных между несколькими запросами внутри транзакции.Но тем не менее позволяет сделать это без блокировок, хотя конечно есть нюансы.

д0kХТолько одним джоином на транзакцию в for update курсоре с изменением
по where curent of или переходом в сериализейбл, что совсе грустно для
много пользовательского режима.Опять не понимаю. Видимо нужно разбирать на примере.

д0kХЕсли программист в оракле работает по другому , это аналогично
режиму грязного чтения в блокировчнике.Oracle никогда не читает незакоммиченных данных другой сессии.

Правильно , оракл читает предыдущую версию.
Если другая сессия закомитится раньше ,
а потом эта сессия изменит закомиченную записть на основании
предыдущей версии, все приплыли.
Есть 2 пользвательский сессии и 3 счета.
нужно с одной счета перекинуть по 10 рублей на 2 других.
остаток на нем 100 рублей
первая читает
100 рублей отнимате 10 и пошет в остаток 90
в это время другая читает предцдущую версию - 100 рублей
и пишет в остаток 90.
Комитится первая комитится вторая .
на счету должно быть 80 рублей , а у нас 90.
что бы избежать этого артефакта остаток
по счету где 100 рублей нужно читать в режиме
select for update в всех сессиях кто планирует менять остатки .
и изменять никак по другому как через where curent of

Мимобижалд0kХОракл по умолчанию никак не гарантирует согласованность
данных между несколькими запросами внутри транзакции.
Это как так? )

Это по концептам :)
консистентность в режиме рид комитед
распостраняется на момент старта каждого из запросов внутри транзакции.
у следующего запроса внутри одной транзакции другой SCN
и консистентность разных запросов считается от разных исходных,
2 запроса консистентны сами в себе ,
но с точки зрения транзакции данные получаемые этими запросами не консистентны.
хотите консистентности на уровне транзакции идите в сериализейбл.

NETClientд0kХЭто по концептам :)
консистентность в режиме рид комитед
распостраняется на момент старта каждого из запросов внутри транзакции.
у следующего запроса внутри одной транзакции другой SCN
и консистентность разных запросов считается от разных исходных,
2 запроса консистентны сами в себе ,
но с точки зрения транзакции данные получаемые этими запросами не консистентны.
хотите консистентности на уровне транзакции идите в сериализейбл.Какую задачу мы решаем? Сделать перевод со счета на два других? Для (банковских) систем - это всегда две разные транзакции. Каждая из них осуществляется одним update-запросом.

Мы решаем задачу получения максимального параллелизма выполениния
при сохранении целостности данных определенной бизнес логикой.
С течки зрения банка , это баланс.
с точки зрения ретейла , это соотвествие суммы значений по позициям чеках
разнице остатков на складах и полках.

NETClient
Чего я не понимаю?

как бы так помягче выразиться,
фундаментального понимания процесса построения систем
с высокой конкуренцией использования данных
Инфа для общего развития и более глубокого погружения в тему

Вячеслав Любомудровд0kХС течки зрения банка , это баланс.
с точки зрения ретейла , это соотвествие суммы значений по позициям чеках
разнице остатков на складах и полках.Есть опыт?
Или так, прочитал чей-то высер?

За 20 + лет в ИТ опыта полно всякого и разного.