Представьте примерочную в магазине. Когда человек заходит внутрь, он закрывает дверь на защелку. Пока он там, никто другой зайти не сможет — ресурс временно «захвачен». В мире баз данных эта защелка называется блокировкой.
В этой статье мы разберем, что такое блокировки в 1С, зачем они нужны, чем объектные блокировки отличаются от транзакционных, и как избежать проблем при параллельной работе пользователей.
Также рассмотрим проблемы связанные с неверной работой блокировок, их отсутствием или напротив - избыточными блокировками.
Разбираемся в терминологии
Если простыми словами - то блокировка данных в 1С - это запись о том, что какой-то ресурс захвачен кем-то для выполнения каких-то действий.
Часть блокировок реализовано средствами самой платформы 1С - они называются объектные блокировки. Другая часть ложится на плечи СУБД - это транзакционные блокировки. Наличие этих двух видов блокировок обусловлено подходами к представлению данных. 1С рассматривает данные в первую очередь как неделимые объекты, которые редактируются целиком - например, карточка конкретного товара, или конкретный документ. А для СУБД все данные - это набор связанных между собой таблиц.
Зачем вообще нужны блокировки в 1С?
1С - многопользовательская система, и должна обеспечивать возможность одновременной записи и чтения различных данных несколькими пользователями, и при этом сохранять целостность, непротиворечивость и достоверность данных. В процессе работы системы возникает конкурентный доступ к ресурсам.
Пример:
Один менеджер проводит документ поступления товаров, а другой в эту же секунду формирует отчет по остаткам на складе. Если первый менеджер запишет данные только наполовину, второй увидит в отчете искаженную картину. Чтобы этого не произошло, система должна грамотно регулировать «очередность» доступа к данным.
Два уровня понимания: 1С и СУБД
Часть блокировок реализуется средствами самой платформы 1С — это объектные блокировки. Другая часть ложится на плечи системы управления базами данных (СУБД) — это транзакционные блокировки.
Почему их две? Дело в разном восприятии данных:
Для 1С данные — это неделимые бизнес-объекты (например, карточка конкретного товара или документ «Реализация»).
Для СУБД (MS SQL, PostgreSQL) никаких «документов» не существует. Для нее данные — это просто набор связанных между собой таблиц с колонками и строками.
Стакан наполовину пуст? Объектные блокировки: Пессимисты и Оптимисты
Объектные блокировки контролируются платформой 1С. Они бывают двух видов, и их названия отлично отражают суть их работы.
Пессимистическая блокировка
Логика: «Объект-пессимист» уверен, что как только вы начнете его читать, кто-то другой обязательно попытается его испортить. Поэтому он сразу вешает замок.
Пессимистическая блокировка накладывается в момент начала редактирования данных (при открытии формы или кодом) и гарантирует, что вы точно сможете сохранить свои изменения.
Пример:
Менеджер А открыл карточку номенклатуры «Стул офисный» и начал менять цену. В это время Менеджер Б тоже пытается открыть этот же стул для редактирования. 1С не даст ему этого сделать и выдаст предупреждение: «Объект заблокирован пользователем Менеджер А».
Оптимистическая блокировка
Логика: «Объект-оптимист» верит в лучшее. Он считает, что пока вы работаете с данными, никто их не тронет. Он не блокирует объект при открытии, но делает проверку версии объекта в момент записи.
Пример:
Два менеджера одновременно открыли один и тот же документ продаж. Менеджер А изменил комментарий и нажал «Записать» — всё прошло успешно (версия объекта в базе обновилась). Менеджер Б в своем окне тоже поменял скидку и нажал «Записать». Но тут 1С выдаст ошибку: «Данные были изменены другим пользователем». Оптимизм не оправдался, Менеджеру Б придется переоткрыть документ, чтобы увидеть актуальные данные и внести изменения заново.
Транзакционные блокировки (Уровень СУБД)
Как видно из названия, эти блокировки тесно связаны с понятием транзакции.
Транзакция работает по принципу «всё или ничего». Либо все действия внутри нее успешно записываются в базу, либо при любой ошибке происходит полный откат, словно ничего и не было.
В 1С транзакционные блокировки делятся на два режима:
1. Автоматические блокировки
Здесь всем управляет сама СУБД. Разработчику 1С не нужно писать дополнительный код, что очень упрощает разработку. Но есть существенный минус — избыточность блокировок (эскалация).
Пример:
Мы проводим оплату от покупателя Иванова. При автоматическом режиме СУБД для надежности может заблокировать всю таблицу взаиморасчетов. В итоге, пока транзакция Иванова не завершится, другой пользователь будет сидеть и ждать (смотреть на «песочные часы»), чтобы просто провести оплату от Петрова, хотя это совершенно разные клиенты!
2. Управляемые блокировки
Это блокировки, которыми рулит собственный менеджер блокировок 1С, независимо от используемой СУБД. Этот режим требует от разработчика ручного написания кода, но зато дает филигранную точность.
Пример:
Мы проводим ту же оплату от Иванова. В управляемом режиме 1С точечно наложит блокировку только на те строки в таблице взаиморасчетов, которые касаются именно Иванова. В это же время второй менеджер без всяких задержек проведет оплату от Петрова. Параллельность работы возрастает в разы!
Ошибки из-за неправильной работы транзакционных блокировок
При одновременном чтении и изменении одних и тех же данных конкурирующими транзакциями могут возникать серьезные аномалии. Вот 4 классические проблемы:
Проблема потерянных изменений (когда одна транзакция затирает результаты другой).
Проблема «грязного» чтения (чтение данных, которые еще не зафиксированы другой транзакцией и могут быть отменены).
Проблема неповторяющегося чтения (в рамках одной транзакции один и тот же запрос дважды выдает разные данные, потому что между ними вклинилась другая транзакция).
Проблема чтения фантомов (когда меняется не конкретная строка, а количество строк, попадающих под условие запроса).
Если система спроектирована неверно или используются некорректные уровни изоляции, пользователи неизбежно столкнутся с этими проблемами.
Более подробно вы можете ознакомиться например, в статье Википедии.
И еще кое-что: миф про блокировки S, X, U
Из статьи в статью, с сайта на сайт кочует один и тот же текст про виды блокировок на уровне СУБД:
S (Shared) — разделяемая блокировка для чтения;
X (eXclusive) — исключительная блокировка для записи;
U (Update) — блокировка для обновления.
Всё бы ничего, но мало кто уточняет, что это терминология исключительно MS SQL Server! Да, у MS SQL таких видов блокировок более 20, а 1С использует в основном эти три. Но не стоит забывать, что мир баз данных шире.
Например, в Oracle используются свои блокировки: RS (Row Share), RX (Row Exclusive), TX и другие. А в PostgreSQL вообще балом правит механика MVCC (многоверсионность), где подходы к блокировкам строк совершенно иные.
Широкое распространение аббревиатур S, X и U связано с тем, что исторически связка 1С + MS SQL Server была самой популярной в корпоративном сегменте. Однако сегодня ситуация меняется.
Совет: воспринимайте информацию критически. Глубже вникайте в архитектуру той СУБД, с которой работаете. Кто знает, возможно, именно это знание поможет вам однажды блеснуть на собеседовании на должность Senior-разработчика 1С!
Чувствуете, что застряли в основах 1С?
Информация в интернете кажется обрывочной, а на решение простых задач уходят часы? Вы не одиноки. Я запустил Клуб для 1С разработчиков Alexcode.PRO. Внутри - продвинутые статьи, видео, материалы для скачивания, закрытый чат для резидентов и возможность влиять на контент.