Мастер-группа. Тема №10. Объектные блокировки
09.02.2011
комментариев 12
Продолжаем тематические сессии мастер-группы.
Сегодня говорим об объектных оптимистических и пессимистических блокировках.
Эта тема не заслуженно оставляется специалистами “на потом”. Хотя сложного ничего нет, а знать этот материал важно.
Представляем вам 14 видео-уроков:
1. Введение.
2. Предназначение. Объектные и транзакционные блокировки.
3. Объектная пессимистическая блокировка.
4. Блокировка объекта при изменении реквизита формы, не являющегося реквизитом объекта. Управляемые формы.
5. Блокировка объекта при изменении реквизита формы, не являющегося реквизитом объекта. Обычные формы.
6. Объектная оптимистическая блокировка.
7. Программная работа с блокировками. Синтаксис методов.
8. Программная установка блокировки в обычной форме.
9. Проверка блокировки объекта.
10. Сложности установки блокировки в управляемых формах.
11. Синтаксис методов блокировки для управляемых форм.
12. Установка блокировки в управляемых формах.
13. Практическое применения свойства “Версия данных”.
14. Применимость объектных блокировок на практике.
Видео интересно и понравилось.
Хотел бы уточнить такие вопросы:
Получается объектные и транзакционные блокировки все равно связанны, а не как совсем отдельные механизмы.
Если у нас конфигурация в управляемом режиме блокировок. Мы открыли какой-то документ, т.е прочитали его из СУБД. После прочтения блокировка у нас должна быть сразу же снята(т.к. в управляемом режиме уровень изоляции ReadCommit).
С пессиместической вроде понятно, на уровне кластера серверов блокирует изменения. А оптиместичная как? при изменении объекта она сравнивает “Версию данных” у данного объекта? Но если к нам “подкрались” через СУБД и после нашего прочтения сделали Update, а версию данных не поменяли, т.к. это лишь поле в таблице. и в результате наши изменения затрут, сделанные из СУБД. Или же при прочтении объекта, программа устанавливает уровень изоляции транзакции выше и блокировка в СУБД на таблице документа держится до окончания транзакции(открытия нашего документа)
>Получается объектные и транзакционные блокировки все равно связанны, а не как совсем отдельные механизмы.
Все-таки это отдельные механизмы.
Заблокированный объектной блокировкой объект может быть изменен программным образом.
>при изменении объекта она сравнивает «Версию данных» у данного объекта
Именно так.
> Но если к нам «подкрались» через СУБД и после нашего прочтения сделали Update, а версию данных не поменяли, т.к. это лишь поле в таблице.
Да, такое изменение может быть потеряно.
Это одна из причин по которой 1С запрещает (на уровне лицензионного соглашения) менять данные любыми средствами, кроме самой платформы.
Но если, уровень блокирок автоматический, то они даже через СУБД не смогут подменить данные.
Давайте рассмотрим на примере.
Вы говорите о такой ситуации:
Пользователь открыл элемент справочника и его редактирует.
Служебное задание средствами СУБД меняет элементы справочников, не изменяя версию данных.
Блокировки автоматические.
Все верно?
В этом случае пользователь при выполнении Записи элемента затрет изменения сделанные средствами СУБД.
Да, вы правильно поняли вопрос.
Т.е. интерактивное открытие элемента справочника (чтение его данных из СУБД) будет внетранзакционным чтением и мы можем прочитать хлам из незавершенных транзакций?
Теперь понятна суть вопроса.
Грязного чтения платформа не допускает.
То есть во время открытия элемента будет накладываться транзакционная блокировка и тут же сниматься.
Но все же утверждать, что объектные блокировки порождают транзакционные неверно. Например, первые можно наложить программным образом (метод Заблокировать), в этом случае на уровне СУБД ничего не произойдет.
Грязное чтение у нас всякий раз, когда мы читаем данные вне транзакции. Например если какая-нибудь ОСВ считывает данные не открыв транзакцию.
Только при работе на Оракле или Постресе (версионниках) его не может быть по определению.
Вы меня не правильно поняли.
В данном примере платформа не допустит грязного чтения. Если элемент модифицируется в транзакции (а если быть более точным – на этот элемент накладывается блокировка), то открытие этого элемента в другом сеансе невозможно до окончания транзакции.
Т.е. если подытожить вопрос по объектные блокировки.
Независимо от того какой уровень блокировок установлен для конфигурации автоматический или управляемый. При интерактивном чтении, платформа считывает из СУБД в транзакции данные(ставит блокировку чтения) и тут же ее снимает(т.е транзакция длится только пока мы открывали объект), а дальше он ведет себя как самостоятельный объект в памяти и при записи в СУБД сравнивает свою версию с предыдущей.
Все верно, Тимур.
Когда снимается блокировка методом Заблокировать() при некорректном завершении сеанса из которого вызывался метод?
Для клиент-серверного режима?
Для файлового режима?
Используем метод “Заблокировать()” в обычных формах для блокировки одновременного выполнения некоторых действий в информационной базе, при отключении компьютера от сети установленная им блокировка “живет” ~5 минут для клиент-серверного варианта. После этого сессия закрывается и блокировка пропадает. Есть ли возможность управлять периодом, который живет “блокировка”.
Пока живо соединение с ИБ живет и блокировка.
Периодом блокировки нельзя управлять.