Здравствуйте!

Есть Транзакция №1, которая записала данные в регистр. Дальше после записи в регистр Транзакцией №1 и до момента чтения остатков из регистра Транзакцией №1 случилась Транзакция № 2, которая изменила итоги в регистре, но еще не зафиксировала данные.

Вопрос: Почему на момент времени чтения остатков Транзакцией №1 будут получены данные с учетом не зафиксированной Транзакции №2 - Ведь это ГРЯЗНОЕ ЧТЕНИЕ. А ведь в управляемом режиме блокировками уровень изоляции ReadCommiting, который исключает грязное чтение!!!

Или в данном случае (когда включен режим разделения итогов) - это является исключением и тут возможно грязное чтение ?

Спасибо за внимание.

Где-то ты накосячил. БлокироватьДляИзменения отключает разделитель итогов до конца транзакции. Т.е. Транзакция №2 не могла изменить итоги в регистре.

боже.. опять ... http://infostart.ru/public/196565

(1)Я хочу понять, если не отключать разделение итогов. Что будет. Грязное чтение ?
(2)это я уже прочитал
Меня интересует только один вопрос. Чтобы избежать грязного чтения ?

Как описано в руководстве разработчика:

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

Ведь по сути это грязное чтение - чтение не зафиксированных данных Транзакцией №2.

Да не, вроде не должно быть такой фигни и без БлокироватьДляИзменения... БД какая?

(3) (4)  если установили "блокироватьдляизменения", не запишет вторая транзакция ничего, ибо будет ждать окончания транзакции №1

(4) если "блокироватьдляизменения" не указано, блокировка будет снята сразу по окончании записи движений в регистр, и до момента чтения возможно изменение итогов другой транзакцией, следовательно и будут прочитаны неверные "грязные" итоги

(4)MS SQL Server 2005.
Но выходит что так, есть место для грязного чтения из таблицы итогов рег. накопления, при условии что мы не установили БлокироватьДляИзменения = Истина

(5)с этим и так ясно

(6)Все теперь ясно. Значить в данном случае грязное чтение имеет место быть

Не-не-не! Что ясно? Вторая транзакция еще не зафиксирована. MSSQL при READ COMMITED не должен был дать первой транзакции прочитать данные без учета разделителя, т.к. часть данных в этот момент залочены второй транзакцией.

(0) А как именно ты читаешь? Запросом?

(8) нет, блокировка накладывается с момента записи набора регистров и до окончания транзакции а если отсутствует "БлокироватьДляИзменения" то в (2) описано к чему это приведет. Конечно надо обсуждать конкретный код.

Мне не понятен вот этот абзац из http://infostart.ru/public/196565

Если используется версионник

В этом случае, заблокированные строки первой транзакции, никак не помешают 2-й транзакции прочитать остатки (т.к. в версионнике пишущие не блокируют читающих).



Вторая транзакция спокойно прочитает старую версию данных (версию на момент начала первой транзакции) и спишет остаток в минус.

Что бы этого не допустить нужна управляемая блокировка на уровне 1С.

Если поставить БлокироватьДляИзменения = Истина, мы как раз получим такую блокировку, и данные будут заблокированы на уровне платформы.


Что такое версионник ?
>>т.к. в версионнике пишущие не блокируют читающих
     => Т.е. данные будут прочитаны только по разделителю Транзакции №1 без учета внесенных изменений Транзакцией № 2?

https://www.google.ru/?gfe_rd=cr&ei=065LU6G9C5GWwAPL-4G4Aw#newwindow=1&q=версионники+vs+блокировочники

Версионирование и блокировки - два подхода для разрешения коллизий параллельных транзакций в СУБД. MSSQL - блокировочная СУБД, но в последних версиях можно использовать и версионирование. PostgreSQL - версионник.

(14)точно. Спасибо

Гы. А в 8.3 1С юзает MSSQL как раз в режиме версионирования. Как-то я провтыкал этот момент.