READ_COMMITTED_SNAPSHOT и автоматический режим блокировки данных #733799

Исходя из того, что при включенном параметре базы MSSQL READ_COMMITTED_SNAPSHOT вне транзакций чтение происходит из версий (без грязного чтения), сделал следующее предположение. Если для базы с автоматическим режимом блокировок включить этот параметр, то уровень изоляции в транзакциях не изменится, но вне транзакций чтение станет негрязным. Иначе говоря никаких ухудшений логики работы системы не появится. Вот нашел косвенное подтверждение Кто нибудь еще пробовал?

И без SNAPSHOT чтенние тоже не будет грязным...

даже в авто режиме?

А какая разница, при записи блокируются записи исключительной блокировкой и чтение будет ожидать...

Фактически именно с SNAPSHOT можем получить грязное чтение, так как получив состояние базы до начала транзакции может возникнуть ситуация, когда алгоритм оперирует одними данными, а данные уже изменились (транзакция изменяющая данные завершилась успешно)

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

чтение вне транзакции ожидать не будет

У что, у сервера ms sql есть режим READ UNCOMMITTED SNAPSHOT ?

У что -> А что

Или речь про 8.3, которая так и читает вне транзакций?

Резюмирую: 1) 8.2 так делать не будет, так как она в любом режиме вне транзакций читает в режиме Read_Uncommited, что запросом, что в списках. Snapshot не поможет. 2) 8.3 так и делает, как сказал автор.

Понятно. Сомнения у меня были именно про работу в автоматическом режиме.

Ты счаст тоже зародил во мне сомнения по поводу авт. режима для 8.3 :-)  Но, скорее всего, так и есть. Но - мало ли! Проверить - стоит!

Проверил на 8.3. Сомнения подтвердились. READ_COMMITTED_SNAPSHOT проверяется 1Ской в режиме "Автоматический и управляемый" и "Управляемый", а в режиме "Автоматический" динамический список отображает незафиксированные изменения.

Да, Read_Uncommited  (with nolock)

Интересно, почему так сделали. Ведь могли бы и для автоматического режима поддержать параметр READ_COMMITTED_SNAPSHOT.

Спроси на семинаре, почему периодический РС при записи накладывает управляемую блокировку по всему диапазону периода.

ну и спроси.

Единственное объяснение, которое придумал - для защиты результатов виртуальных таблиц СрезПоследних и родственных.

+ По сути это похоже на блокирование таблицы остатков у остальных типов регистров при их записи, только ее здесь физически нет, но все равно защищается как бы виртуальные таблицы.

Скорее всего оно. Я сам невдуплил.

Потому что декларируется поддержка SQL2000, а в нём нет снапшот-изоляции

Тогда почему же для управляемого режима работает?

ну да, не изменится, был repeateble read/serialized, а стал read commited (точнее его аналогом)

прочитал 5 раз, не понял в чем вопрос. можете перефразировать для особо тупых?

ТС хотел добиться, чтобы в автоматическом режиме чтение вне транзакции осуществлялось в режиме Read Committed Snapshot. Но 1С как ни крути читает с Read_Uncommited (with nolock)

а, понял, спасибо.

А не проще перевести конфигурацию в "Автоматический и управляемый", ведь Автоматический режим это устаревший? В 8.3 может быть и реальной таблицей, в новых версиях. Что, конечно, никак не влияет на идею блокировок. Если бы хотели, то эта функция могла бы включаться если её СУБД поддерживает.

Перевести на режим "Автоматический и управляемый" теперь, когда я знаю такое важное отличие от "Автоматический", конечно здравое решение.

Изменения в 8.3.6 Поле Период, установленное в отборе набора записей периодического регистра сведений, включается в набор полей, по которым устанавливается управляемая блокировка при чтении или записи набора записей. В режиме совместимости с версией 8.3.5 поведение не изменилось. Похоже все таки признали такое поведение не оптимальным.