Представим, что нам необходимо хранить данные, и мы всю нашу информацию записываем в файл. Пока мы работаем одни (монопольный доступ), то никаких проблем не возникает. Но если появляется хотя бы 2 пользователя, то уже есть вероятность некоторых проблем.
Проблема 1. Потерянное обновление.
При изменении одних данных двумя разными транзакциями в одно и то же время, одно из изменений перезапишется другим (потеряется).
Например, мы изменили Сумму заказа № 154, в это время второй пользователь тоже изменил сумму заказа № 154 и записал изменения. Но мы еще не закончили работать с объектом и внесли еще одно изменение, скажем, указали комментарий и записали изменения. Т.к. файл с данными объекта у нас уже был открыт, то изменения второго пользователя будут потеряны.
Для решения такой проблемы, необходимо запретить начало изменения объекта, если он уже изменяется кем-то. Или другими словами, запретить изменение объекта, если есть активная транзакция.
Проблема 2. Грязное чтение.
Чтение добавленных/измененных данных, но которые впоследствии отменятся.
Например, мы изменили сумму в заказе, второй пользователь их прочитал. Но мы передумали и не зафиксировали изменения (отменили транзакцию). Получается, что пользователь прочитал данные, которых, как бы и не существовало.
Для решения такой проблемы, необходимо запретить даже читать данные заказа, если он кем-то изменяется. Или другими словами, надо запретить читать данные, если они используются активной транзакцией.
Проблема 3. Неповторяемое чтение.
В рамках одной транзакции мы запрашиваем данные в СУБД, и при втором запросе данные отличаются от тех, которые были в первом.
Например, мы получили Сумму заказа, и на основании нее приняли решение сформировать второй заказ. В это время второй пользователь изменил первичные данные. Таким образом, перед записью второго заказа, если мы проверим сумму первого заказа, она будет не той, на основании которой мы приняли решение создавать второй заказ.
Т.е. данные во время нашей работы изменяются другими пользователями или другими словами, на начало операции и на конец операции, мы прочитаем разные данные (уже зафиксированные).
Для решения такой проблемы, необходимо другим пользователям запретить изменять заказ, если мы прочитали его данные, но пока не завершили все свои операции. Или другими словами, надо запрещать изменять данные другим пользователям, если мы их хотя бы просто прочитали в рамках активной транзакции.
Проблема 4. Чтение фантомов.
В рамках одной транзакции мы запрашиваем данные в СУБД, и при втором запросе количество данных становится больше, чем было в первом (появляются фантомы).
Например, существует таблица, у которой есть индекс по полям «Фамилия, Имя, Отчество» (таблица Физические лица). Представим, что пользователь в рамках транзакции выполняет запрос:
ВЫБРАТЬ
*
ИЗ
Таблица.ФизическиеЛица
ГДЕ
Фамилия = &Фамилия
И Имя = &Имя
И Отчество = &Отчество Предположим, что по ФИО «Ефимов Константин Юрьевич» вернулась 1 запись. Не смотря на то, что СУБД будет защищать прочитанную запись от изменения, может возникнуть ситуация, что при повторном запросе нам вернется 2 записи, потому что другая транзакция добавит еще одно физическое лицо с таким же ФИО.
Т.е. мы защищали одну запись, но не защищали весь диапазон «ФИО», чтобы никто не смог добавить с таким же ФИО новую запись.
Для решения такой проблемы необходимо так же защищать и соседние записи, чтобы не было добавлено строк между ними.
Выводы
Проблемы конкурентного доступа решаются в СУБД разными степенями защиты данных или Уровнями изоляции транзакций:
- Потерянное обновление решается на уровне READ UNCOMMITED.
- Грязное чтение решается на уровне READ COMMITED.
- Неповторяемое чтение решается на уровне REPEATABLE READ.
- Чтение фантомов решается на уровне SERIALIZABLE.
Данная тема подробнее рассматривается в пакете видео-курса «Секреты 1С: Эксперта» Шаг 3. Занятие 09-01 Знакомство с блокировками СУБД..
