Извиняюсь за цитату:
"...в то время когда юзер А делает "долгий" селект (9 сек), юзер Б втыкает в таблицу новые записи (аналогично выглядит пример с UPDATE вместо INSERT).
При этом SELECT для юзера А выглядит атомарным и вражеские поползновения юзера Б не влияют на результат А.
...
Что произойдет в КАШЭ??? При использовании SQL? При использовании низкоуровневого подхода?"

Длительные изыскания привели меня (с помощью Intersystems.ru) к след. выводам:
1) уровень изолированности "snapshot" (или "read repeatable" - "восстановимое чтение") в СУБД Cache' НЕ поддерживается (по каким-то ихним принципиальным соображениям, об этом в хелпе у них даже написано)
Т.о., пользователь "A" по окончании своей _долгой_ выборки УВИДИТ данные, измененные юзверем "Б" (хочет он того или нет :-))
2) уровень изолир-сти "read committed" поддерживается, но тут есть ОЧЕНЬ важные замечания:
2.0. конкурентные процессы должны использовать при доступе к одним и тем же данным ЛИБО синтаксис SQL, ЛИБО синтаксис Cache Object Script. Плохо, если первый процесс использует SQL, а второй - COS.
2.1. ИСПОЛЬЗОВАНИЕ СИНТАКСИСА SQL:
2.1.1. команды типа select max(Id) from mytable, select count(*) from mytable (короче, команды с агрегатными функциями) - все равно будут видеть "грязные" данные. Разработчики СУБД объясняют это
a) соображениями производительности и тем, что
b) учет "грязных" данных ИМЕННО в таких командах НЕ приведет к разрушительным последствиям (если, конечно, Вы не собираетесь использовать их результаты как используют значения "последовательностей" в терминах Оракла или "генераторов" в терминах Интербейза)
2.1.2. прочие DML-команды, "обрамленные" инструкциями объявления и открытия SQL-курсора, при "грязных" данных НЕ увидят. При попытке прочесть командой &sql(fetch...) строку, которую другой процесс сейчас изменяет, возникнет SQLCODE=-114, который можно перехватить (и, при желании, как-то реагировать на него)
2.2 ИСПОЛЬЗОВАНИЕ СИНТАКСИСА CACHE' OBJECT SCRIPT:
2.2.1. Сразу после сохранения объекта командой типа s retcode=myobj.%Save() следует проверить, что Каше его действительно сохранил и открыть этот объект с ИСКЛЮЧИТЕЛЬНОЙ БЛОКИРОВКОЙ. Например, так:
i retcode {
s NewId=myobj.%Id()
s ObjOpen=..%OpenId(NewId, 4):nnn
}
2.2.2. Обратите внимание на:
a) второй параметр в функции %OpenId() - число 4.
Это как раз означает, что ДРУГИЕ процессы НЕ смогут открыть обновленный только что объект.
b) nnn, записанное после двоеточия - это таймаут в секундах (например, 5). Если его не указать, то в случае, когда этот объект будет открыт на другой станции, Ваш процесс будет казаться зависшим - на самом деле он будет тупо ждать, когда объект освободится.

Главный вывод: ВСЕ процессы, которые потенциально могут обращаться к одним и тем же данным в конкурентном режиме, должны использовать ЛИБО SQL-синтаксис, ЛИБО Cache' Object Script - но БЕЗ перемешивания.

Вспомогательный вывод:
Очевидно, что функция G(n) будет иметь зависимость 1/log(n), где
G - количество геморроя для каждого разработчика;
n - общее число разработчиков.

Вроде, всё. Извините за многословность.