Пересечение транзакций. Примеры

Рассматривается пересечение транзакций типа чтение-запись над одним элементом справочника при разных уровнях изоляции.

Рассмотрим две пересекающихся во времени исполнения транзакции, которые читают и затем записывают элемент справочника. Обозначим операции первой транзакции большими буквами RWO, операции второй транзакции – малыми буквами rwo. Используем буквы от операций Read, Write, cOmmit или rOllback. Команду «НачатьТранзакцию» нет смысла отслеживать, поскольку создание Snapshot, блокировка данных и прочие значимые события происходят при первом обращении к данным.

Формально, все возможные варианты запуска операторов по времени:

RrwWOo	RrwWoO	RrwoWO
RrWwoO	RrWwOo	RrWOwo
RWrwoO	RWrwOo	RWrOwo

Однако не все из них могут быть выполнены. Последовательность выполнения изменяется блокировками. Поэтому порядок выполнения чтения/записи будет отличаться от порядка запуска операторов.

1. В режиме автоматических блокировок Repetable Read

чтение устанавливает разделяемую блокировку СУБД до конца транзакции (название обязывает), запись устанавливает исключительную блокировку до конца транзакции.

При запуске в последовательности (RrwWOo, RrwWoO, RrwoWO) выйдет сообщение СУБД о взаимоблокировке из-за повышения уровня блокировки в этих двух транзакциях. Откатится транзакция, которая попытается записать первой. Порядок выполнения будет RrwoWO.
При запуске в последовательности (RrWwoO, RrWwOo, RrWOwo) выйдет сообщение СУБД о взаимоблокировке из-за повышения уровня блокировки в этих двух транзакциях. Откатится транзакция, которая попытается записать первой. Порядок выполнения будет RrWOwo.
При запуске в последовательности (RWrwoO, RWrwOo, RWrOwo) порядок выполнения будет RWOrwo. Запись завершится успешно.

2. В режиме управляемых блокировок, совместимость 8.2

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

2.1 Если СУБД MS SQL, уровень изоляции RC.

Исключительные блокировки возникают при записи, и разделяемые при чтении (только на момент чтения).

При запуске в последовательности (RrwWOo, RrwWoO, RrwoWO) порядок выполнения будет RrwoWO. Откатится транзакция, которая попытается записать второй. Сообщение платформы: Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!
При запуске в последовательности (RrWwoO, RrWwOo, RrWOwo) порядок выполнения будет RrWOwo. Откатится транзакция, которая попытается записать второй. Сообщение платформы: Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!
При запуске в последовательности (RWrwoO, RWrwOo, RWrOwo) порядок выполнения будет RWOrwo. Запись завершится успешно.

3. В режиме управляемых блокировок, совместимость 8.3

3.1 Если СУБД MS SQL 2008 и выше, уровень изоляции RCSI.

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

При запуске в последовательности (RrwWOo, RrwWoO, RrwoWO) порядок выполнения будет RrwoWO.
При запуске в последовательности (RrWwoO, RrWwOo, RrWOwo) порядок выполнения будет RrWOwo.
При запуске в последовательности (RWrwoO, RWrwOo, RWrOwo) порядок выполнения будет RWrOwo.

В каждом случае платформа покажет ошибку: Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!

Это связано с тем, что вторая транзакция прочитает данные по состоянию на начало первой транзакции, незафиксированные (nocomitted) действия первой транзакции ей не доступны. В момент записи происходит повторное чтение, сравнивается версия объекта. Платформа обнаруживает, что версия не соответствует и запускает откат транзакции. Если бы мы работали не с объектным типом данных, а с регистром сведений у которого нет поля версии, то проверка версии перед записью была невозможна. Может поэтому для метода Прочитать() регистра сведений предусмотрены разделяемые управляемые блокировки.

Для проверки написал обработку, которая запускает операторы чтения/записи по расписанию

фрагменты кода обработки

Процедура НачатьТестНаСервере(НомерТранзакции)

ПараметрыТранзакции1 = Новый Массив;
ПараметрыТранзакции2 = Новый Массив;

Для кк = 1 ПО 6 цикл
Вырезка = Сред(объект.Наименование,кк,1);
ВырезкаКод = КодСимвола(Вырезка,1);

Если ВРег(Вырезка) <> "R" И ВРег(Вырезка) <> "W" И ВРег(Вырезка) <> "O" Тогда
Сообщить("Непредусмотренный символ " + Вырезка);
КонецЕсли;

Если ВырезкаКод > КодСимвола("Z",1) Тогда
ПараметрыТранзакции1.Добавить(Вырезка);
ПараметрыТранзакции2.Добавить( "ожидание" );
Иначе
ПараметрыТранзакции1.Добавить( "ожидание" );
ПараметрыТранзакции2.Добавить(Вырезка);
КонецЕсли;
КонецЦикла;

//Служебный.ТестированиеПересечения(Объект.ЭлементСправочника,ЗначениеВСтрокуВнутр(ПараметрыТранзакции1),""+Объект.Код+Объект.Наименование,Объект.Ожидание);

Если НомерТранзакции <> 2 Тогда

ПараметрыВыполнения = Новый Массив;
ПараметрыВыполнения.Добавить( Объект.ЭлементСправочника );
ПараметрыВыполнения.Добавить( ЗначениеВСтрокуВнутр(ПараметрыТранзакции1) );
ПараметрыВыполнения.Добавить( ""+Объект.Код+Объект.Наименование );
ПараметрыВыполнения.Добавить( Объект.Ожидание );
ФоновыеЗадания.Выполнить("Служебный.ТестированиеПересечения", ПараметрыВыполнения);

КонецЕсли;

Если НомерТранзакции <> 1 Тогда

ПараметрыВыполнения = Новый Массив;
ПараметрыВыполнения.Добавить( Объект.ЭлементСправочника );
ПараметрыВыполнения.Добавить( ЗначениеВСтрокуВнутр(ПараметрыТранзакции2) );
ПараметрыВыполнения.Добавить( ""+Объект.Код+Объект.Наименование );
ПараметрыВыполнения.Добавить( Объект.Ожидание );
ФоновыеЗадания.Выполнить("Служебный.ТестированиеПересечения", ПараметрыВыполнения);

КонецЕсли;

КонецПроцедуры


Процедура ТестированиеПересечения( ЭлементСправочника1, Параметр1, МеткаЗапроса, Ожидание) Экспорт

Массив1 = ЗначениеИзСтрокиВнутр( Параметр1 );

Ожидание( Ожидание );

Запрос = Новый Запрос;
Запрос.Текст = ("ВЫБРАТЬ "" "+МеткаЗапроса+" "" ");
РезультатЗапроса = Запрос.Выполнить();

НачатьТранзакцию();

Для КК = 0 по Массив1.Количество()-1 Цикл

текВремя = ТекущаяДата();

Если Врег( Массив1[КК] ) = "R" Тогда
Объект1 = ЭлементСправочника1.ПолучитьОбъект();
ИначеЕсли Врег( Массив1[КК] ) = "W" Тогда
Объект1.Записать();
ИначеЕсли Врег( Массив1[КК] ) = "O" Тогда
ЗафиксироватьТранзакцию();
КонецЕсли;

Ожидание( Ожидание, текВремя );

КонецЦикла;

КонецПроцедуры


Процедура Ожидание(Сек, текВремя = 0) Экспорт

Если Сек = 0 Тогда
Возврат;
КонецЕсли;

Если текВремя = 0 Тогда
текВремя = ТекущаяДата();
КонецЕсли;

Пока ТекущаяДата() < текВремя + Сек Цикл

КонецЦикла;

КонецПроцедуры

Слайды для пункта 1

В тексте видно уровень изоляции Repeatable Read.Первая транзакция запущена в сеансе 54, вторая транзакция запущена в сеансе 57. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RrwWOo – указана в строке 12:20:51.

После чтения в строках 12:20:51 и 12:20:53 обе транзакции установили на справочник разделяемые блокировки. Поэтому запись в строке 12:20:55 завершиться не может, происходит deadlock.

В 12:20:59 выходит ошибка: Конфликт блокировок при выполнении транзакции: Microsoft SQL Server Native Client 11.0: Транзакция (идентификатор процесса 57) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно. Вторая транзакция завершается rollback, первая транзакция устанавливает блокировку, производит запись и commit. Фактический порядок выполнения RrwoWO.

В тексте видно уровень изоляции Repeatable Read.Первая транзакция запущена в сеансе 57, вторая транзакция запущена в сеансе 54. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RWrwoO – указана в строке 12:39:43. После записи в строке 12:39:45 транзакция установила на справочник исключительную блокировку. Поэтому вторая транзакция смогла установить блокировку и начать работать только в 12:39:53 после ожидания 6 секунд. Фактический порядок выполнения RWOrwo.

Слайды для пункта 2.1

В тексте видно уровень изоляции Read Commited. Первая транзакция запущена в сеансе 54, вторая транзакция запущена в сеансе 56. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RrwWOo – указана в строке 13:20:25.

Транзакция, которая первой произведет запись и установит блокировку, будет commit, транзакция, которая попытается записать позже будет rollback: Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)! Фактический порядок исполнения RrwoWO.

В тексте видно уровень изоляции Read Commited. Первая транзакция запущена в сеансе 56, вторая транзакция запущена в сеансе 54. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RWrwOo – указана в строке 14:49:52.

Вторая транзакция должна прочитать в 14:49:56, но из-за исключительной блокировки вынуждена дожидаться окончания первой. Фактический порядок исполнения RWOrwo.

Слайды для пун кта 3.1

Первая транзакция запущена в сеансе 55, вторая транзакция запущена в сеансе 58. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RWrwOo – указана в строке 10:18:25.

В 10:18:31 должна была выполниться запись. Но блокировка передвинула запись после commit, 10:18:33. В результате получилась последовательность RWrOwo. Вторая транзакция rollback.

Первая транзакция запущена в сеансе 55, вторая транзакция запущена в сеансе 58. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RrWwoO – указана в строке 10:16:19.

В 10:16:25 должна была выполниться запись. Но блокировка передвинула запись после commit, 10:16:29. В результате получилась последовательность RrWOwo. Вторая транзакция rollback.

Первая транзакция запущена в сеансе 58, вторая транзакция запущена в сеансе 55. Операторы запускаются равномерно каждые 2 секунды. Последовательность запуска RrwWoO – указана в строке 10:13:25.

В 10:13:31 должна была выполниться запись. Но блокировка передвинула запись после commit, 10:13:33. В результате получилась последовательность RrwoWO. Первая транзакция rollback.

Заключение.

Мы рассмотрели основные варианты поведения программы 1С и СУБД MS SQL при пересечении транзакций. В случае, если статья наберет больше 50 звездочек, добавлю информацию Postgres. Ниже первый вариант статьи. Для читабельности и простоты пришлось отказаться от многого. Основная картинка к статье — изолятор штыревой. Игра слов с "уровень изоляции транзакции".

Тысячи тонн словесной руды

Изучал документацию Postgres, сравнивал с MS SQL. Захотел с кем-то обсудить новую информацию – написал статью. ~~Украл, выпил — в тюрьму. Романтика.~~

Cайт разработчика Postgres Professional https://postgrespro.ru/education

список видео-уроков https://postgrespro.ru/education/courses/DBA2

Краткое содержание видео-урока 2.Изоляция транзакций. https://www.youtube.com/watch?v=QU2PVSnBGEY&index=2&list=PLaFqU3KCWw6JgufXBiW4dEB2-tDpmOXPH

05-00 Стандарты изоляции SQL.

06-30 Особенности изоляции в Postgres после 9.5. Добавлен феномен «аномалия сериализации» и применяются более строгие условия. https://postgrespro.ru/docs/postgrespro/9.5/transaction-iso. Разработчики оправдывают это тем, что в стандарте SQL 92 не прописано, каким образом обеспечивать ссылочную целостность. Возможны два принципиально разных подхода СУБД: версионники и блокировочники. Соответственно, уровни изоляции стандарта SQL 92 в разных СУБД реализованы по разным алгоритмам.

08-00 время создания снимка данных (Snapshot) в зависимости от уровня изоляции. Не по команде begin transaction, а при первом обращении к данным или при каждом обращении к данным.

11-00 уровень изоляции для новых транзакций

14-30 Можно выполнить set transaction isolation level read uncommited, сообщения об ошибке не будет, Show transaction isolation вернет read uncommited, но грязного чтения не произойдет. Поскольку Postgres является версионником по архитектуре, и отсутствует грязное чтение, то уровни изоляции Read uncommitted, Read committed, Read committed snapshot для этой СУБД совпадают.

18-30 read commited практические примеры видимость версий данных для транзакции. Команда delete не удалила все строки: была открыта другая транзакция.

31-00 repeatable read практические примеры

34-00 ошибки сериализации, если строка была изменена с момента транзакции.

35-00 Serializable практические примеры. Если использовать, то все транзакции должны быть этого-же уровня. Аномалия сериализации – ситуация, когда результат одновременного (параллельного) выполнения транзакций отличается от результата последовательного выполнения этих же транзакций. Если в pg две транзакции записи с уровнем изоляции Serializable выполняются над одним набором данных, то будет отказана та транзакция, которая не успеет сделать commit первой. (Для сравнения, в управляемых блокировках при конфликте откатывается транзакция, которая захватила меньше данных. Интересная стратегия, да ?)

41-00 итоги

44-00 ответы на вопросы

48-00 предикатные блокировки

50-00 конец

Если найдете неточности или ошибки – сообщайте, буду признателен (USD, EUR, SM). Про изоляции есть хорошие статьи //infostart.ru/public/559967/, //infostart.ru/public/708848/. Постараюсь не повторяться.

Итак, изоляция транзакции – это показатель, насколько в ней допускаются несогласованные данные (Филиппов Е., стр. 38). В pg-документации несогласованность данных называется «феномен».

Уровни изоляции описаны стандартом SQL 92 https://docs.microsoft.com/ru-ru/dotnet/framework/data/adonet/sql/snapshot-isolation-in-sql-server

Уровень изоляции	«Грязное» чтение		Неповторяемое чтение		Фантомное чтение		Аномалия сериализации
	pg	ms	pg	ms	pg	ms	pg
Read uncommited (Чтение незафиксированных данных)	Нет*	Да	Да	Да	Да	Да	Да
Read committed (Чтение зафиксированных данных)	Нет	Нет	Да	Да	Да	Да	Да
Repeatable read (Повторяемое чтение)	Нет	Нет	Нет	Нет	Нет*	Да	Да
Serializable (Сериализуемость)	Нет	Нет	Нет	Нет	Нет	Нет	Нет

Потерянное обновление не допускается в любом случае при использовании транзакции.

Нет* = Допускается, но не в PG, а сторонними утилитами и представлениями.

В случае, если Изоляция моментальных снимков Read committed = False, в статье https://docs.microsoft.com/ru-ru/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-2024 указано: «READ_COMMITTED_SNAPSHOT находится в состоянии OFF» — используется блокировка.

Пункт 2. Изменяя вручную средствами MS SQL флаг Изоляция моментальных снимков Read committed в платформе 8.3.11, мы нарушаем лицензионное соглашение. В конфигураторе выполним: Администрирование – Выгрузить информационную базу, Администрирование – Загрузить информационную базу. В режиме совместимости 8.2 флаг не сохраняет свое значение, изменяется на false. В режиме совместимости 8.3 флаг не сохраняет свое значение, изменяется на true. Если какая-то опция в MS SQL изменена и сохраняет свое значение при выгрузке-загрузке базы данных средствами 1С, то опцию можно изменять в рамках лицензионного соглашения средствами MS SQL. Возможно, этот флаг можно изменять при использовании платформы 8.2. Иначе бы не было статьи //infostart.ru/public/91879/ .

Пункт 3. флаг настройки «Разрешить изоляцию моментальных снимков». Позволяет применять уровень изоляции Snapshot. Если флаг = Истина, команды SQL отработают без ошибок

SET TRANSACTION ISOLATION LEVEL SNAPSHOT

begin transaction

Если флаг = Ложь, выходит ошибка “режим изоляции моментального снимка не допускается в этой базе данных”. Более подробно можно посмотреть в документации https://technet.microsoft.com/ru-ru/library/jj856598(v=sql.110).aspx. У меня сложилось впечатление, что Snapshot для MS SQL – это реализация уровня Serializable стандарта SQL 92 с использованием версионности. Уровень изоляции Snapshot на экзамене мы не рассматриваем (Е.Филиппов, стр. 39).

Полезная информация: уровни изоляции по умолчанию в таблице (Е.Филиппов, стр. 41).

		8.2	8.3
Автоматические блокировки
MS SQL	Записей	Repetable read; Serializable	Repetable read; Serializable
PostgreSQL	Таблиц	Serializable	Serializable
Файловая	Таблиц	Serializable	Serializable
Управляемые блокировки
MS SQL 2000	Записей	Read commited	Read commited
MS SQL 2005 и выше	Записей	Read commited	Read commited Snapshot
PostgreSQL	Записей	Read commited	Read commited
Файловая	Таблиц	Serializable	Serializable

5 Comments

nvv1970 04.09.2018 at 07:41

Вот это жесть.

Rwrwowororowwwrwrwrw — вообще не читабельно.

Если честно, то такой ерундой я занимался после первого прочтения книжки Филиппова. Это не знания. Это метод тыка. Какую-то задачу в понимании блокировок он решает, но до конца понять а почему всё-таки так — не получится.

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

Пока мне показалось, что понимания у вас маловато. Может показалось.

По статье. Она с мутными и непонятным обозначениями. А разобранные примеры не несут никакой пользы.

Reply ↓
vasilev2015 04.09.2018 at 09:14

(1) Здравствуйте !

Все началось с просмотра ролика postgres. Там были примеры по пересекающимся транзакциям в СУБД. Лектор сразу предупредил, что это не читабельно и жесть. По факту это часть документации СУБД и стандарт отрасли. Блокировки и изоляции пригодятся на экзамене, поэтому я захотел разобраться, чтобы не говорить общими словами, что при повышении уровня изоляции возможны deadlock. Предполагается, что читатель уже знает, чем отличаются изоляции RR, RC, RCSI. Думаете нужна была еще одна теоретическая статья про уровни изоляции и блокировки ?

Reply ↓
nvv1970 04.09.2018 at 10:22

(2) нет, еще одна не нужна. Но какие нибудь выступления Пилюгина по MSSQL делают эту тему более понятной, чем курсы Богачева и экзамен эксперта.

Reply ↓
vasilev2015 04.09.2018 at 10:37

(3) Виктор Богачев — хороший человек, я бы писал его фамилию с большой буквы. В остальном, спасибо за рецензию. )))

Reply ↓
nvv1970 04.09.2018 at 10:38

(4) Прошу прощения )) С вашим мнением согласен ))

Reply ↓