Просмотр исходного текста страницы Инфраструктура System.Transactions в мире .NET

''<blockquote>[[:Категория:Георгий Минашин (Статьи)|Георгий Минашин]], наш старший разработчик C#, опубликовал на портале [https://habr.com/top/ «Хабр»] пост, посвященный инфраструктуре System.Transactions. Что такое транзакции и&nbsp;когда они&nbsp;бывают полезны? Обязательно ли использовать СУБД для&nbsp;поддержания целостности данных? Какие инструменты для&nbsp;управления транзакциями есть в&nbsp;.NET? Об этом — в материале [https://habr.com/company/custis/blog/433136/?fbclid=IwAR0foaC79lM9v4CjP8XDWmBwPWL23TaRP0OaPkOYvvaElPqJrjzO7GP7z6I «Инфраструктура System.Transactions в мире .NET»].</blockquote>''

Встречали&nbsp;ли вы&nbsp;в&nbsp;C# конструкцию типа <code>using (var scope = new TransactionScope(TransactionScopeOption.Required))</code>? Это значит, что код, выполняющийся в&nbsp;блоке <code>using</code>, заключается в&nbsp;транзакцию и&nbsp;после выхода из&nbsp;этого блока изменения будут зафиксированы или отменены. Звучит понятно, пока не&nbsp;начинаешь копать глубже. И&nbsp;чем глубже копаешь, тем &laquo;страньше и&nbsp;страньше&raquo; становится. Во&nbsp;всяком случае, у&nbsp;меня при&nbsp;более близком знакомстве с&nbsp;классом <code>TransactionScope</code> и&nbsp;вообще транзакциями .NET возникла целая уйма вопросов.

Что за&nbsp;класс <code>TransactionScope</code>? Как только мы&nbsp;используем конструкцию <code>using (var scope = new TransactionScope())</code>, все в&nbsp;нашей программе сразу становится транзакционным? Что такое &laquo;управляющий ресурсами&raquo; (Resource Manager) и&nbsp;&laquo;управляющий транзакциями&raquo; (Transaction Manager)? Можно&nbsp;ли написать свой управляющий ресурсами и&nbsp;как он&nbsp;&laquo;подключается&raquo; к&nbsp;созданному экземпляру <code>TransactionScope</code>? Что такое распределенная транзакция и&nbsp;правда&nbsp;ли, что распределенная транзакция в&nbsp;SQL Server или Oracle Database&nbsp;&mdash; это то&nbsp;же самое, что и&nbsp;распределенная транзакция .NET?

В&nbsp;данной публикации я&nbsp;постарался собрать материал, помогающий найти ответы на&nbsp;указанные вопросы и&nbsp;сформировать понимание транзакций в&nbsp;мире .NET.

== Введение ==

=== Что такое транзакции и какие проблемы они решают ===

Транзакции, о&nbsp;которых здесь идет речь,&nbsp;&mdash; это операции, переводящие систему из&nbsp;одного приемлемого состояния в&nbsp;другое и&nbsp;гарантированно не&nbsp;оставляющие систему в&nbsp;неприемлемом состоянии даже при&nbsp;возникновении непредвиденных ситуаций. Что это за&nbsp;приемлемые состояния, в&nbsp;общем случае зависит от&nbsp;контекста. Здесь мы&nbsp;будем считать приемлемой ситуацию, в&nbsp;которой обрабатываемые нами данные целостны. При&nbsp;этом подразумевается, что изменения, составляющие транзакцию, все вместе либо совершаются, либо не&nbsp;совершаются. Кроме того, изменения одной транзакции могут быть изолированы от&nbsp;изменений, вносимых в&nbsp;систему другой транзакцией. Основные требования, предъявляемые к&nbsp;транзакциям, обозначаются аббревиатурой ACID. Для&nbsp;первого знакомства с&nbsp;ними подойдет [https://ru.wikipedia.org/wiki/ACID статья в&nbsp;«Википедии»].

[[File:unacceptable.png|center|200px]]

Классический пример транзакции&nbsp;&mdash; перевод денег между двумя счетами. В&nbsp;этой ситуации снятие денег со&nbsp;счета &#8470;&nbsp;1&nbsp;без зачисления на&nbsp;счет &#8470;&nbsp;2&nbsp;неприемлемо, точно так&nbsp;же, как и&nbsp;зачисление на&nbsp;счет &#8470;&nbsp;2&nbsp;без&nbsp;снятия со&nbsp;счета &#8470;&nbsp;1. Другими словами, мы&nbsp;хотим, чтобы обе операции&nbsp;&mdash; и&nbsp;снятие, и&nbsp;зачисление&nbsp;&mdash; выполнялись сразу. Если&nbsp;же какую-то из&nbsp;них выполнить не&nbsp;удастся, то&nbsp;и&nbsp;вторая операция выполняться не&nbsp;должна. Можно называть этот принцип &laquo;все или ничего&raquo;. Более того, желательно, чтобы операции выполнялись синхронно даже в&nbsp;случае таких системных сбоев, как отключение электроэнергии, то&nbsp;есть чтобы мы&nbsp;видели систему в&nbsp;приемлемом состоянии, как только она&nbsp;станет доступна после восстановления.

В&nbsp;математических терминах можно сказать, что относительно системы существует инвариант, который мы&nbsp;хотели&nbsp;бы обязательно сохранить. Например, сумма на&nbsp;обоих счетах: нужно, чтобы после транзакции (перевода денег) сумма осталась такой&nbsp;же, как и&nbsp;до&nbsp;нее. Кстати, в&nbsp;классическом примере с&nbsp;переводом денег еще и&nbsp;фигурирует учет&nbsp;&mdash; предметная область, где естественным образом возникло понятие транзакции.

Проиллюстрируем пример с&nbsp;переводом денег между двумя счетами. На&nbsp;первой картинке изображена ситуация, когда перевод 50&nbsp;рублей со&nbsp;счета &#8470;&nbsp;1&nbsp;на счет &#8470;&nbsp;2&nbsp;завершился успешно. Зеленый цвет подчеркивает, что система находится в&nbsp;приемлемом состоянии (данные целостны).

[[File:Транзакция 1.png|center|600px]]

Теперь представим, что перевод осуществляется вне транзакции и&nbsp;после снятия денег со&nbsp;счета &#8470;&nbsp;1&nbsp;произошел сбой, из-за которого снятые деньги не&nbsp;были начислены на&nbsp;счет &#8470;&nbsp;2. Система окажется в&nbsp;неприемлемом состоянии (красный цвет).

[[File:Транзакция 2.png|center|600px]]

Если&nbsp;же ошибка произошла между операциями снятия и&nbsp;зачисления, но&nbsp;перевод осуществлялся в&nbsp;рамках одной транзакции, то&nbsp;операция снятия денег будет отменена. В&nbsp;результате система останется в&nbsp;исходном приемлемом состоянии.

[[File:Транзакция 3.png|center|600px]]

Приведу примеры ситуаций из&nbsp;опыта нашей компании, в&nbsp;которых транзакции бывают полезны: учет товаров (учет количества товаров разных видов, которые находятся в&nbsp;определенных хранилищах и&nbsp;в&nbsp;пути), учет ресурсов хранилищ (учет объема помещения, который занимают товары определенного типа, объема помещения, свободного для размещения товаров, количества товаров, которое могут переместить сотрудники и&nbsp;автоматизированные системы хранилища за&nbsp;день).

Проблемы, возникающие при&nbsp;нарушении целостности данных, очевидны. Информация, предоставляемая системой, не&nbsp;просто становится недостоверной&nbsp;&mdash; она теряет связь с&nbsp;действительностью и&nbsp;превращается в&nbsp;бессмыслицу.

=== Какие транзакции здесь рассматриваются ===

Предоставляемые транзакциями выгоды известны. Так что&nbsp;же, для&nbsp;поддержания целостности данных нам нужна реляционная база данных, поскольку именно там делаются транзакции? Не&nbsp;совсем. Выше было сказано, что понятие транзакции зависит от&nbsp;контекста, и&nbsp;сейчас кратко рассмотрим, о&nbsp;каких транзакциях можно говорить при обсуждении информационных систем.

Для начала разделим понятия транзакций предметной области (бизнес-транзакций) и&nbsp;системных транзакций. Вторые могут быть реализованы в&nbsp;разных местах и&nbsp;разными способами.

Зайдем с&nbsp;самого высокого уровня&nbsp;&mdash; предметной области. Интересант может объявить, что существуют некоторые приемлемые состояния и&nbsp;он&nbsp;не&nbsp;желает видеть информационную систему вне&nbsp;этих состояний. Не&nbsp;будем придумывать лишних примеров: перевод денег между счетами здесь подходит. Только уточним, что перевод&nbsp;&mdash; это не&nbsp;обязательно перевод денег между расчетными счетами двух клиентов банков. Не&nbsp;менее важна и&nbsp;задача бухгалтерского учета, когда счета должны отражать источники и&nbsp;предназначение средств организации, а&nbsp;перевод&nbsp;&mdash; изменение распределения средств по&nbsp;этим источникам и&nbsp;предназначению. Это был пример <b>транзакции предметной области</b>.

Теперь посмотрим самые распространенные и&nbsp;интересные примеры реализации системных транзакций. В&nbsp;системных транзакциях разными техническими средствами обеспечиваются требования предметной области. Классическим проверенным решением такого рода являются '''транзакции реляционных СУБД''' (первый пример). Современные системы управления БД (как реляционными, [https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_tp так и&nbsp;не&nbsp;очень]) предоставляют механизм транзакций, который позволяет или&nbsp;сохранить (зафиксировать) все сделанные за&nbsp;указанный период работы изменения, или отказаться от&nbsp;них (откатить). При использовании такого механизма операции снятия денег с&nbsp;одного счета и&nbsp;зачисления на&nbsp;другой счет, составляющие транзакцию предметной области, средствами СУБД будут объединены в&nbsp;системную транзакцию и&nbsp;либо выполнятся вместе, либо не&nbsp;выполнятся вовсе.

Пользоваться СУБД, конечно, не обязательно. Грубо говоря, можно вообще реализовать механизм транзакций СУБД на&nbsp;своем любимом языке программирования и&nbsp;наслаждаться неустойчивым и&nbsp;заваленным ошибками аналогом существующих инструментов. Зато ваш &laquo;велосипед&raquo; может быть оптимизирован для конкретных ситуаций предметной области.

Есть и&nbsp;более интересные варианты. Современные промышленные языки программирования (C# и&nbsp;Java в&nbsp;первую очередь) предлагают средства, предназначенные специально для организации транзакций с&nbsp;участием совершенно разных подсистем, а&nbsp;не&nbsp;только СУБД. В&nbsp;данной публикации будем называть такие транзакции программными. В&nbsp;случае C# это <b>транзакции из&nbsp;пространства имен System.Transactions</b> (второй пример), именно о&nbsp;них и&nbsp;рассказывается ниже.

Прежде чем перейти к&nbsp;транзакциям <code>System.Transactions</code>, нельзя не&nbsp;упомянуть еще одно интересное явление. Средства <code>System.Transactions</code> позволяют программисту самостоятельно реализовать [https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C программную транзакционную память]. В&nbsp;этом случае программные операции, влияющие на&nbsp;состояние системы (в&nbsp;случае классических императивных языков программирования это операция присваивания), по&nbsp;умолчанию включаются в&nbsp;транзакции, которые можно фиксировать и&nbsp;откатывать почти так&nbsp;же, как и&nbsp;транзакции СУБД. При таком подходе необходимость использовать механизмы синхронизации (в&nbsp;C#&nbsp;&mdash; <code>lock</code>, в&nbsp;Java&nbsp;&mdash; <code>synchronized</code>) значительно снижается. Дальнейшим развитием этой идеи является <strong>программная транзакционная память, поддерживаемая на&nbsp;уровне платформы</strong> (третий пример). Такое чудо ожидаемо обнаруживается в&nbsp;языке, изящность которого превосходит его промышленную применимость,&nbsp;&mdash; Clojure. А&nbsp;для рабоче-крестьянских языков существуют подключаемые библиотеки, предоставляющие функциональность программной транзакционной памяти.

Системные транзакции могут включать несколько информационных систем, в&nbsp;таком случае они становятся распределенными. Распределенными могут быть и&nbsp;транзакции СУБД, и&nbsp;программные; все зависит от&nbsp;того, какую функциональность поддерживает конкретное средство реализации транзакции. Подробнее распределенные транзакции рассматриваются в&nbsp;соответствующем разделе. Приведу картинку, чтобы было легче разобраться в&nbsp;обсуждаемых предметах.

[[File:Виды транзакций.png|center|600px]]

=== TL;DR по разделу ===

Существуют процессы, которые состоят из&nbsp;нескольких неделимых (атомарных) операций, применяемых к&nbsp;системе, в&nbsp;общем случае не&nbsp;обязательно информационной. Каждая неделимая операция может оставить систему в&nbsp;неприемлемом состоянии, когда целостность данных нарушается. Например, если перевод денег между двумя счетами представлен двумя неделимыми операциями снятия со&nbsp;счета &#8470;&nbsp;1&nbsp;и&nbsp;зачисления на&nbsp;счет &#8470;&nbsp;2, то&nbsp;выполнение только одной из&nbsp;этих операций нарушит целостность данных. Деньги или&nbsp;пропадут неизвестно куда, или&nbsp;появятся неизвестно откуда. Транзакция объединяет неделимые операции так, чтобы они выполнялись все вместе (разумеется, последовательно, если это необходимо) или не&nbsp;выполнялись вообще. Можно говорить о&nbsp;транзакциях предметной области и&nbsp;о&nbsp;транзакциях в&nbsp;технических системах, которые обычно реализуют транзакции предметной области.

== Транзакции на основе System.Transactions ==

=== Что это ===

В&nbsp;мире .NET существует программный каркас, предназначенный создателями платформы для&nbsp;управления транзакциями. С&nbsp;точки зрения программиста, пользующегося транзакциями, этот каркас состоит из&nbsp;типов <code>TransactionScope</code>, <code>TransactionScopeOption</code>, <code>TransactionScopeAsyncFlowOption</code> и&nbsp;<code>TransactionOptions</code> пространства имен <code>System.Transactions</code>. Если говорить про .NET Standard, то&nbsp;все это доступно начиная с&nbsp;[https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md версии&nbsp;2.0].

Транзакции из&nbsp;пространства имен <code>System.Transactions</code> основываются на&nbsp;[http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf стандарте X/Open XA от&nbsp;консорциума The Open Group]. В&nbsp;этом стандарте вводятся многие термины, обсуждаемые далее, и,&nbsp;главное, описываются распределенные транзакции, которым в&nbsp;данной публикации также посвящен специальный раздел. На&nbsp;этом же стандарте основываются реализации программных транзакций и&nbsp;в&nbsp;других платформах, например [https://ru.wikipedia.org/wiki/Java_Transaction_API в&nbsp;Java].

Типовой сценарий использования транзакций для программиста&nbsp;C# следующий:
<code-csharp>using (var scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required))
{
    // Какой-то транзакционный код, например работа с СУБД.
    scope.Complete();
}</code-csharp>

Внутри блока <code>using</code> помещается код, выполняющий работу, результаты которой должны быть зафиксированы или отменены все вместе. Классические примеры такой работы&nbsp;&mdash; это чтение и&nbsp;запись в&nbsp;БД или&nbsp;отправка и&nbsp;получение сообщений из&nbsp;очереди. Когда управление покинет блок <code>using</code>, транзакция будет зафиксирована. Если убрать вызов <code>Complete</code>, то&nbsp;транзакция откатится. Довольно просто.

Получается, что во&nbsp;время отката транзакции все операции, сделанные внутри такого блока <code>using</code>, будут отменены? И&nbsp;если я&nbsp;присвоил какой-нибудь переменной другое значение, то&nbsp;у&nbsp;этой переменной восстановится старое значение? Когда я&nbsp;впервые увидел подобную конструкцию, то&nbsp;так и&nbsp;подумал. На&nbsp;самом деле, конечно, откатятся не&nbsp;все изменения, а&nbsp;только очень <i>особенные</i>. Если&nbsp;бы откатывались вообще все изменения, то&nbsp;это и&nbsp;было&nbsp;бы программной транзакционной памятью, описанной выше. А&nbsp;сейчас посмотрим, что это за&nbsp;особенные изменения, которые могут участвовать в&nbsp;программных транзакциях на&nbsp;основе <code>System.Transactions</code>.

=== Управляющие ресурсами ===

Чтобы нечто поддерживало транзакции на&nbsp;основе <code>System.Transactions</code>, нужно, чтобы оно&nbsp;обладало информацией о&nbsp;том, что в&nbsp;данный момент идет транзакционная работа, и&nbsp;чтобы оно&nbsp;регистрировалось в&nbsp;каком-то реестре участников транзакции. Получить информацию о&nbsp;том, идет&nbsp;ли транзакционная работа, можно, проверив статическое свойство <code>Current</code> класса <code>System.Transactions.Transaction</code>. Вход в&nbsp;блок <code>using</code> указанного выше вида как раз устанавливает это свойство, если оно&nbsp;не&nbsp;было установлено раньше. А&nbsp;чтобы зарегистрироваться как участник транзакции, можно использовать методы типа <code>Transaction.Enlist<i>Smth</i></code>. Кроме этого, нужно реализовать интерфейс, требуемый данными методами. Управляющий ресурсами (Resource Manager)&nbsp;&mdash; это именно такое &laquo;нечто&raquo;, поддерживающее взаимодействие с&nbsp;транзакциями из&nbsp;<code>System.Transactions</code> (более конкретное определение дано ниже).

Какие бывают управляющие ресурсами? Если мы&nbsp;работаем из&nbsp;C# с&nbsp;СУБД, например SQL Server или&nbsp;Oracle Database, то&nbsp;обычно пользуемся соответствующими драйверами, а&nbsp;они и&nbsp;являются управляющими ресурсами. В&nbsp;коде они представляются типами <code>System.Data.SqlClient.SqlConnection</code> и&nbsp;<code>Oracle.ManagedDataAccess.Client.OracleConnection</code>. Еще, [http://fukyo-it.blogspot.com/2012/02/truly-understanding-net-transactions.html говорят], MSMQ поддерживает транзакции на&nbsp;основе <code>System.Transactions</code>. Руководствуясь знаниями и&nbsp;примерами, почерпнутыми из&nbsp;интернета, можно создать и&nbsp;собственный управляющий ресурсами. Простейший пример приведен в&nbsp;следующем разделе.

Кроме управляющих ресурсами, у&nbsp;нас должен быть еще управляющий транзакциями (Transaction Manager), который будет следить за&nbsp;транзакцией и&nbsp;своевременно отдавать распоряжения управляющим ресурсами. В&nbsp;зависимости от&nbsp;того, какие управляющие ресурсами участвуют в&nbsp;транзакции (какие у&nbsp;них характеристики и&nbsp;где они&nbsp;расположены), к&nbsp;работе подключаются разные управляющие транзакциями. При этом выбор подходящей версии происходит автоматически и&nbsp;не&nbsp;требует вмешательства программиста.

Если говорить конкретнее, то&nbsp;управляющий ресурсами&nbsp;&mdash; это экземпляр класса, реализующего специальный интерфейс <code>System.Transactions.IEnlistmentNotification</code>. Экземпляр класса по&nbsp;указанию клиента регистрируется как участник транзакции, пользуясь статическим свойством <code>System.Transactions.Transaction.Current</code>. В&nbsp;дальнейшем управляющий транзакциями по&nbsp;мере необходимости вызывает методы указанного интерфейса.

[[File:Управляющие.png|center|600px]]

Ясно, что во&nbsp;время выполнения может изменяться набор управляющих ресурсами, участвующих в&nbsp;транзакции. Например, после входа в&nbsp;блок <code>using</code> мы&nbsp;можем сначала сделать что-то в&nbsp;SQL Server, а&nbsp;потом&nbsp;&mdash; в&nbsp;Oracle Database. В&nbsp;зависимости от&nbsp;такого набора управляющих ресурсами и&nbsp;определяется используемый управляющий транзакциями. Если быть точнее, то&nbsp;по&nbsp;набору управляющих ресурсами определяется используемый транзакционный протокол, а&nbsp;уже на&nbsp;основе протокола определяется поддерживающий его&nbsp;управляющий транзакциями. Транзакционные протоколы мы&nbsp;рассмотрим позже, когда будем говорить о&nbsp;распределенных транзакциях. Механизм автоматического выбора подходящего управляющего транзакциями во&nbsp;время выполнения при изменении участвующих в&nbsp;транзакции управляющих ресурсами называется продвижением транзакции (Transaction Promotion).

=== Виды управляющих ресурсами ===

Управляющие ресурсами можно разделить на&nbsp;две большие группы: долговечные и&nbsp;непостоянные.

Долговечный управляющий ресурсами (Durable Resource Manager)&nbsp;&mdash; управляющий ресурсами, который поддерживает транзакцию даже в&nbsp;случае недоступности информационной системы (например, при перезапуске компьютера). Непостоянный управляющий ресурсами (Volatile Resource Manager)&nbsp;&mdash; управляющий ресурсами, который не&nbsp;поддерживает транзакцию в&nbsp;случае недоступности информационной системы. Непостоянный управляющий ресурсами поддерживает транзакции только в&nbsp;оперативной памяти.

Классические долговечные управляющие ресурсами&nbsp;&mdash; это СУБД (или драйвер СУБД для программной платформы). Что&nbsp;бы ни&nbsp;произошло&nbsp;&mdash; хоть сбой в&nbsp;работе операционной системы, хоть отключение электроэнергии,&nbsp;&mdash; СУБД будет гарантировать целостность данных после того, как она снова придет в&nbsp;рабочее состояние. За&nbsp;это, разумеется, приходится платить некоторыми неудобствами, но&nbsp;в&nbsp;данной статье мы&nbsp;их&nbsp;рассматривать не&nbsp;будем. Пример непостоянного управляющего ресурсами&nbsp;&mdash; упомянутая выше программная транзакционная память.

=== Использование TransactionScope ===

При создании объекта типа <code>TransactionScope</code> можно указывать некоторые параметры.

Во-первых, есть настройка, сообщающая среде выполнения о&nbsp;том, что нужно: 

1) пользоваться уже существующей к&nbsp;этому моменту транзакцией; 

2) обязательно создавать новую; 

3) наоборот, выполнять код внутри блока <code>using</code> вне транзакции.

За все это отвечает перечисление <code>System.Transactions.TransactionScopeOption</code>.

Во-вторых, можно задать уровень изоляции транзакции. Это параметр, который позволяет найти компромисс между независимостью изменений и&nbsp;скоростью работы. Самый независимый уровень&nbsp;&mdash; сериализуемый&nbsp;&mdash; гарантирует, что не&nbsp;существует таких ситуаций, когда изменения, внесенные в&nbsp;рамках одной еще не&nbsp;зафиксированной транзакции, можно увидеть в&nbsp;другой транзакции. Каждый следующий уровень добавляет по&nbsp;одной такой конкретной ситуации, когда одновременно выполняющиеся транзакции могут влиять друг на&nbsp;друга. По&nbsp;умолчанию транзакция открывается на&nbsp;сериализуемом уровне, что&nbsp;может быть неприятно (см., например, [https://habr.com/company/custis/blog/433136/#comment_19531318 этот комментарий]).

Настройка уровня изоляции транзакции при&nbsp;создании <code>TransactionScope</code> носит рекомендательный характер для&nbsp;управляющих ресурсами. Они&nbsp;могут даже не&nbsp;поддерживать все уровни, представленные в&nbsp;перечислении <code>System.Transactions.IsolationLevel</code>. Кроме того, надо учитывать, что при использовании пула соединений для&nbsp;работы с&nbsp;БД соединение, для&nbsp;которого был изменён уровень изоляции транзакции, по&nbsp;возвращении в&nbsp;пул [https://yarfullstack.com/post/2017-03/isolation-level-and-connection-pool/ сохранит этот уровень]. Теперь, когда программист получит это&nbsp;соединение из&nbsp;пула и&nbsp;положится на&nbsp;значения по&nbsp;умолчанию, он&nbsp;будет наблюдать неожиданное поведение.

Типовые сценарии работы c&nbsp;TransactionScope и&nbsp;существенные подводные камни (а&nbsp;именно вложенные транзакции) хорошо освещены в&nbsp;[https://habr.com/post/115480/ этой статье на&nbsp;«Хабре»].

=== Применимость программных транзакций ===

Следует сказать, что почти в&nbsp;любой информационной системе, находящейся в&nbsp;промышленной эксплуатации, запускаются процессы, которые могут привести систему в&nbsp;неприемлемое состояние. Поэтому бывает необходимо контролировать эти процессы, выяснять, является&nbsp;ли текущее состояние системы приемлемым, и, если нет, восстанавливать его. Программные транзакции&nbsp;&mdash; готовый инструмент для&nbsp;поддержания системы в&nbsp;приемлемом состоянии.

В&nbsp;каждом конкретном случае конструктивно было бы рассматривать стоимость:

1) интеграции процессов в&nbsp;инфраструктуру программных транзакций (нужно, чтобы эти процессы знали о&nbsp;<code>TransactionScope</code> и&nbsp;о&nbsp;многих других вещах);

2) поддержания этой инфраструктуры (например, стоимость аренды оборудования с&nbsp;Windows на&nbsp;борту);

3) обучения сотрудников (так как тема транзакций .NET мало распространена).

Нельзя забывать и&nbsp;о&nbsp;том, что от&nbsp;транзакционного процесса может потребоваться сообщать о&nbsp;своем прогрессе &laquo;внешнему миру&raquo;, например вести журнал действий вне&nbsp;транзакции.

Очевидно, отказ от&nbsp;программных транзакций потребует создания или&nbsp;внедрения какого-то другого средства поддержания целостности данных, которое также будет иметь свою стоимость. В&nbsp;конце концов, возможны случаи, когда нарушения целостности данных так редки, что проще восстанавливать приемлемое состояние системы оперативными вмешательствами, чем поддерживать механизм автоматического восстановления.

=== Пример непостоянного управляющего ресурсами ===

Сейчас рассмотрим пример простейшего управляющего ресурсами, не&nbsp;поддерживающего восстановление после системного сбоя. У&nbsp;нас будет блок программной транзакционной памяти, хранящий некоторое значение, которое можно читать и&nbsp;перезаписывать. В&nbsp;отсутствие транзакции этот блок ведет себя как обычная переменная, а&nbsp;при&nbsp;наличии транзакции он&nbsp;сохраняет начальное значение, которое может быть восстановлено после отката транзакции. Код такого управляющего ресурсами представлен далее:
<code-csharp>internal sealed class Stm<T> : System.Transactions.IEnlistmentNotification {
    private T _current;
    private T _original;
    private bool _enlisted;

    public T Value {
        get { return _current; }
        set {
            if (!Enlist()) {
                _original = value;
            }
            _current = value;
        }
    }

    public Stm(T value) {
        _current = value;
        _original = value;
    }

    private bool Enlist() {
        if (_enlisted)
            return true;
        var currentTx = System.Transactions.Transaction.Current;
        if (currentTx == null)
            return false;
        currentTx.EnlistVolatile(this, System.Transactions.EnlistmentOptions.None);
        return true;
    }

    #region IEnlistmentNotification

    public void Commit(System.Transactions.Enlistment enlistment) {
        _original = _current;
        _enlisted = false;
    }

    public void InDoubt(System.Transactions.Enlistment enlistment) {
        _enlisted = false;
    }

    public void Prepare(System.Transactions.PreparingEnlistment preparingEnlistment) {
        preparingEnlistment.Prepared();
    }

    public void Rollback(System.Transactions.Enlistment enlistment) {
        _current = _original;
        _enlisted = false;
    }

    #endregion IEnlistmentNotification
}</code-csharp>

Видно, что единственным формальным требованием является реализация интерфейса <code>System.Transactions.IEnlistmentNotification</code>. Из&nbsp;интересного стоит отметить методы <code>Enlist</code> (не&nbsp;являющиеся частью <code>System.Transactions.IEnlistmentNotification</code>) и&nbsp;<code>Prepare</code>. Метод <code>Enlist</code> как раз проверяет, работает&nbsp;ли данный код в&nbsp;рамках транзакции, и, если&nbsp;да, регистрирует экземпляр своего класса в&nbsp;качестве непостоянного управляющего ресурсами. Метод <code>Prepare</code> вызывается управляющим транзакциями перед фиксацией изменений. Наш управляющий ресурсами сигнализирует о&nbsp;своей готовности к&nbsp;фиксации, вызывая метод <code>System.Transactions.PreparingEnlistment.Prepared</code>.

Дальше приведен код, показывающий пример использования нашего управляющего ресурсами:
<code-csharp>var stm = new Stm<int>(1);
using (var scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required)) {
    stm.Value = 2;
    scope.Complete();
}</code-csharp>

Если сразу после выхода из&nbsp;блока <code>using</code> прочитать свойство <code>stm.Value</code>, то&nbsp;там ожидаемо будет установленное значение&nbsp;<code>2</code>. А&nbsp;если убрать вызов <code>scope.Complete</code>, то&nbsp;транзакция откатится и&nbsp;в&nbsp;свойстве <code>stm.Value</code> будет значение&nbsp;<code>1</code>, заданное до&nbsp;начала транзакции.

Упрощенно последовательность вызовов при&nbsp;работе с&nbsp;транзакциями <code>System.Transactions</code> показана на&nbsp;приведенной ниже диаграмме.

[[File:Последовательность вызовов.png|center|600px]]

Видно, что в&nbsp;данном примере рассмотрены не&nbsp;все возможности, предоставляемые инфраструктурой <code>System.Transactions</code>. Более полно мы&nbsp;рассмотрим&nbsp;их после того, как познакомимся с&nbsp;транзакционными протоколами и&nbsp;распределенными транзакциями в&nbsp;следующем разделе.

=== TL;DR по разделу ===

Программист может использовать класс <code>TransactionScope</code> для&nbsp;того, чтобы выполнить некоторый код в&nbsp;рамках имеющейся или&nbsp;новой транзакции. Транзакция фиксируется тогда и&nbsp;только тогда, когда у&nbsp;имеющегося экземпляра класса <code>TransactionScope</code> вызывается метод <code>Dispose</code>, при том что перед этим у&nbsp;него был вызван метод <code>Complete</code>. Программист может указывать, желает&nbsp;ли он&nbsp;непременно начать новую транзакцию, воспользоваться уже имеющейся или, наоборот, выполнить код вне&nbsp;имеющейся транзакции. В&nbsp;транзакции участвуют только управляющие ресурсами&nbsp;&mdash; программные компоненты, реализующие определенную функциональность. Управляющие ресурсами могут быть долговечными (восстанавливающимися после сбоя системы) и&nbsp;непостоянными (не&nbsp;восстанавливающимися). СУБД&nbsp;&mdash; пример долговечного управляющего ресурсами. Координацией управляющих ресурсами занимается управляющий транзакциями&nbsp;&mdash; программный компонент, который выбирается исполняющей средой автоматически, без&nbsp;участия программиста.

Непостоянный управляющий ресурсами&nbsp;&mdash; это класс, реализующий интерфейс <code>System.Transactions.IEnlistmentNotification</code> и&nbsp;в&nbsp;методе <code>Prepare</code> подтверждающий свою готовность к&nbsp;фиксации изменений или, наоборот, сигнализирующий об&nbsp;откате изменений. Когда вызывающая сторона что-то делает с&nbsp;управляющим ресурсами, он&nbsp;проверяет, открыта&nbsp;ли сейчас транзакция, и, если открыта, регистрируется с&nbsp;помощью метода <code>System.Transactions.Transaction.EnlistVolatile</code>.

== Распределенные транзакции ==

=== Что это ===

Распределенная транзакция задействует несколько информационных подсистем (на&nbsp;самом деле не&nbsp;все так просто, ниже об&nbsp;этом рассказано подробнее). Подразумевается, что изменения во&nbsp;всех системах, участвующих в&nbsp;распределенной транзакции, должны или фиксироваться, или откатываться.

Выше были представлены разные средства реализации транзакций: СУБД, инфраструктура <code>System.Transactions</code>, встроенная в&nbsp;платформу программная транзакционная память. Этими инструментами могут обеспечиваться и&nbsp;распределенные транзакции. Например, в&nbsp;СУБД Oracle Database изменение (а&nbsp;на&nbsp;самом деле и&nbsp;чтение) данных в&nbsp;нескольких&nbsp;БД в&nbsp;рамках одной транзакции автоматически превращает ее&nbsp;в&nbsp;распределенную. Далее&nbsp;же пойдет речь о&nbsp;программных распределенных транзакциях, которые могут включать разнородные управляющие ресурсами.

=== Транзакционные протоколы ===

Транзакционный протокол&nbsp;&mdash; набор принципов, по&nbsp;которым взаимодействуют участвующие в&nbsp;транзакции приложения. В&nbsp;мире .NET чаще всего встречаются следующие протоколы.

<b>Lightweight.</b> Используется не&nbsp;более одного долговечного управляющего ресурсами. Все транзакционные взаимодействия происходят внутри одного домена приложений, либо управляющий ресурсами поддерживает продвижение и&nbsp;однофазную фиксацию (реализует <code>IPromotableSinglePhaseNotification</code>).

<b>OleTx.</b> Допускается взаимодействие между несколькими доменами-приложениями и&nbsp;несколькими компьютерами. Допускается использование множества долговечных управляющих ресурсами. Все участвующие компьютеры должны находиться под управлением Windows. Используется удаленный вызов процедуры (Remote Procedure Calls, RPCs).

<b>WS-AT.</b> Допускается взаимодействие между несколькими доменами-приложениями и&nbsp;несколькими компьютерами. Допускается использование множества долговечных управляющих ресурсами. Участвующие компьютеры могут находиться под&nbsp;управлением различных&nbsp;ОС, не&nbsp;только Windows. Используется протокол передачи гипертекста (Hypertext Transmission Protocol, HTTP).

Выше было отмечено, что действующий транзакционный протокол влияет на&nbsp;выбор управляющего транзакциями, а&nbsp;на&nbsp;выбор протокола влияют характеристики управляющих ресурсов, участвующих в&nbsp;транзакции. Теперь перечислим известные управляющие транзакциями.

<b>Lightweight Transaction Manager (LTM)</b>. Представлен в .NET Framework&nbsp;2.0 и&nbsp;в&nbsp;более поздних версиях. Управляет транзакциями, использующими протокол Lightweight.

<b>Kernel Transaction Manager (KTM)</b>. Представлен в&nbsp;Windows Vista и&nbsp;Windows Server 2008. Управляет транзакциями, использующими протокол Lightweight. Может вызывать транзакционную файловую систему (Transactional File System, TxF) и&nbsp;транзакционный реестр (Transactional Registry, TxR) в&nbsp;Windows Vista и&nbsp;Windows 2008.

<b>Distributed Transaction Coordinator (MSDTC)</b>. Управляет транзакциями, использующими протоколы OleTx и&nbsp;WS-AT.

Нужно также иметь в&nbsp;виду, что часть управляющих ресурсами не&nbsp;поддерживает все перечисленные протоколы. Например, MSMQ и&nbsp;SQL Server 2000&nbsp;не поддерживают Lightweight, поэтому транзакции с&nbsp;участием MSMQ или SQL Server 2000 будут управляться MSDTC, даже если они&nbsp;являются единственными участниками. Технически это ограничение возникает от&nbsp;того, что указанные управляющие ресурсами, реализуя, конечно, интерфейс <code>System.Transactions.IEnlistmentNotification</code>, не&nbsp;реализуют интерфейс <code>System.Transactions.IPromotableSinglePhaseNotification</code>. В&nbsp;нем есть, кроме прочего, метод <code>Promote</code>, который исполняющая среда вызывает при необходимости перейти на&nbsp;более &laquo;крутой&raquo; управляющий транзакциями.

Сейчас должна стать очевидной неоднозначность понятия распределенной транзакции. Например, можно определять распределенную транзакцию как транзакцию, в&nbsp;которой участвует:

1) не&nbsp;менее двух любых управляющих ресурсами; 

2) сколько угодно непостоянных управляющих ресурсами и&nbsp;не&nbsp;менее двух долговечных; 

3) не&nbsp;менее двух любых управляющих ресурсами, обязательно расположенных на&nbsp;разных компьютерах. 

Поэтому лучше всегда уточнять, о&nbsp;каких именно транзакциях идет речь.

И&nbsp;в&nbsp;этом контексте в&nbsp;первую очередь обсуждается MSDTC. Он&nbsp;представляет собой программный компонент Windows, управляющий распределенными транзакциями. Имеется графический интерфейс для конфигурации и&nbsp;наблюдения за&nbsp;транзакциями, который можно обнаружить в&nbsp;утилите &laquo;Службы компонентов&raquo;, пройдя по&nbsp;пути &laquo;Компьютеры&nbsp;&mdash; Мой компьютер&nbsp;&mdash; Координатор распределенных транзакций&nbsp;&mdash; Локальная DTC&raquo;.

[[File:MSDTC.png|center|600px]]

Для&nbsp;конфигурации нужно выбрать пункт «Свойства» в&nbsp;контекстном меню узла «Локальная DTC», а&nbsp;для&nbsp;наблюдения за распределенными транзакциями — пункт «Статистика транзакций» в&nbsp;центральной панели.

=== Двухфазная фиксация ===

Если в&nbsp;транзакции участвует несколько управляющих ресурсами, то&nbsp;результаты их&nbsp;работы могут отличаться: например, у&nbsp;одного из&nbsp;них все завершилось успешно, и&nbsp;он&nbsp;готов фиксировать изменения, а&nbsp;у&nbsp;другого произошла ошибка, и&nbsp;он&nbsp;собирается откатить изменения. Однако суть распределенной транзакции заключается как раз в&nbsp;том, что изменения всех участвующих в&nbsp;транзакции управляющих ресурсов либо фиксируются все вместе, либо откатываются. Поэтому в&nbsp;таких случаях обычно применяется протокол двухфазной фиксации.

В&nbsp;общем суть этого протокола заключается в&nbsp;следующем. Во&nbsp;время <b>первой фазы</b> участвующие в&nbsp;транзакции управляющие ресурсами подготавливают информацию, достаточную для восстановления после сбоя (если это долговечный управляющий ресурсами) и&nbsp;для&nbsp;успешного окончания работы в&nbsp;результате фиксации. С&nbsp;технической точки зрения управляющий ресурсами сигнализирует о&nbsp;том, что он&nbsp;закончил первую фазу, вызывая метод <code>System.Transactions.PreparingEnlistment.Prepared</code> в&nbsp;методе <code>Prepare</code>. Либо управляющий ресурсами может уведомить об&nbsp;откате изменений, вызвав метод <code>ForceRollback</code>.

Когда все участвующие в&nbsp;транзакции управляющие ресурсами &laquo;проголосовали&raquo;, то&nbsp;есть уведомили управляющий транзакциями о&nbsp;том, хотят&nbsp;ли они фиксировать или&nbsp;откатывать изменения, начинается <b>вторая фаза</b>. В&nbsp;это время управляющие ресурсами получают указание фиксировать свои изменения (если все участники проголосовали за&nbsp;фиксацию) или&nbsp;отказаться от&nbsp;изменений (если хотя&nbsp;бы один участник проголосовал за&nbsp;откат). Технически это выражается в&nbsp;вызове методов <code>Commit</code> и&nbsp;<code>Rollback</code>, которые реализуют управляющие ресурсами и&nbsp;в&nbsp;которых они&nbsp;вызывают метод <code>System.Transactions.Enlistment.Done</code>.

Управляющий ресурсами может вызвать метод <code>System.Transactions.Enlistment.Done</code> и&nbsp;во&nbsp;время первой фазы. В&nbsp;таком случае подразумевается, что он&nbsp;не&nbsp;собирается фиксировать никаких изменений (например, работает только на&nbsp;чтение) и&nbsp;не&nbsp;будет участвовать во&nbsp;второй фазе. Подробнее про двухфазную фиксацию можно прочитать [https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/committing-a-transaction-in-single-phase-and-multi-phase у&nbsp;Microsoft].

Есть еще [https://en.wikipedia.org/wiki/Three-phase_commit_protocol трехфазная фиксация] и&nbsp;ее модификации со&nbsp;своими достоинствами и&nbsp;недостатками. Протокол трехфазной фиксации менее распространен, возможно, потому, что требует еще больше расходов на&nbsp;сообщения между взаимодействующими подсистемами.

=== Шпаргалка по интерфейсам System.Transactions ===

Что-то сложно получается. Чтобы немного разложить все по&nbsp;полочкам, я&nbsp;кратко опишу основные интерфейсы пространства имен <code>System.Transactions</code>, нужные для&nbsp;создания управляющего ресурсами. Вот диаграмма классов.

[[File:Диаграмма классов.png|center|600px]]

<b>IEnlistmentNotification.</b> Управляющий ресурсами обязательно реализует этот интерфейс. Управляющий транзакциями вызывает реализованные методы в&nbsp;следующем порядке. Во&nbsp;время первой фазы он&nbsp;вызывает метод <code>Prepare</code> (если только не&nbsp;сошлись звезды для вызова метода <code>ISinglePhaseNotification.SinglePhaseCommit</code>, о&nbsp;чем написано в&nbsp;следующем пункте). В&nbsp;рамках этого метода управляющий ресурсами сохраняет необходимую для восстановления после сбоя информацию, готовится к&nbsp;окончательной фиксации изменений на&nbsp;своей стороне и&nbsp;голосует за&nbsp;фиксацию или откат изменений. Если наступает вторая фаза, то&nbsp;в&nbsp;зависимости от&nbsp;доступности управляющих ресурсами и&nbsp;от&nbsp;результатов голосования управляющий транзакциями вызывает один из&nbsp;трех методов: <code>Commit</code>, <code>InDoubt</code>, <code>Rollback</code>.

<b>ISinglePhaseNotification.</b> Управляющий ресурсами реализует этот интерфейс, если хочет предоставить управляющему транзакциями возможность оптимизировать выполнение за&nbsp;счет редуцирования второй фазы фиксации. Если управляющий транзакциями видит только один управляющий ресурсами, то&nbsp;на&nbsp;первой фазе фиксации он&nbsp;пытается вызвать у&nbsp;управляющего ресурсами метод <code>SinglePhaseCommit</code> (вместо <code>IEnlistmentNotification.Prepare</code>) и&nbsp;тем самым исключить голосование и&nbsp;переход ко&nbsp;второй фазе. У&nbsp;этого подхода есть достоинства и&nbsp;недостатки, о&nbsp;которых понятнее всего написано у&nbsp;Microsoft [https://msdn.microsoft.com/en-us/library/cc229955.aspx здесь].

<b>ITransactionPromoter.</b> Управляющий ресурсами реализует этот интерфейс (только не&nbsp;напрямую, а&nbsp;через интерфейс <code>IPromotableSinglePhaseNotification</code>), если хочет предоставить управляющему транзакциями возможность придерживаться протокола Lightweight даже при&nbsp;удаленном вызове, пока не&nbsp;наступят другие условия, которые потребуют усложнения протокола. Когда потребуется усложнить протокол, будет вызван метод <code>Promote</code>.

<b>IPromotableSinglePhaseNotification.</b> Управляющий ресурсами реализует этот интерфейс, чтобы, во-первых, реализовать интерфейс <code>ITransactionPromoter</code>, а&nbsp;во-вторых, чтобы управляющий транзакциями мог воспользоваться однофазной фиксацией, вызывая методы <code>IPromotableSinglePhaseNotification.SinglePhaseCommit</code> и&nbsp;<code>IPromotableSinglePhaseNotification.Rollback</code>. Управляющий транзакциями вызывает метод <code>IPromotableSinglePhaseNotification.Initialize</code>, чтобы отметить успешную регистрацию управляющего ресурсами по&nbsp;упрощенной схеме. Более-менее это можно понять из&nbsp;[https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/optimization-spc-and-promotable-spn документа Microsoft].

Еще немного посмотрим на&nbsp;класс <code>System.Transactions.Enlistment</code> и&nbsp;его наследников. Экземпляры этого типа предоставляет управляющий транзакциями, когда вызывает методы интерфейсов, реализуемые управляющим ресурсами.

[[File:Enlistment.png|center|600px]]

<b>Enlistment.</b> Управляющий ресурсами может вызвать единственный метод этого типа&nbsp;&mdash; <code>Done</code>,&nbsp;&mdash; чтобы сигнализировать об&nbsp;успешном выполнении своей части работы.

<b>PreparingEnlistment.</b> С&nbsp;помощью экземпляра этого типа во&nbsp;время первой фазы фиксации управляющий ресурсами может сигнализировать о&nbsp;своем намерении зафиксировать или откатить изменения. Долговечный управляющий ресурсами также может получить информацию, требующуюся для восстановления после системного сбоя.

<b>SinglePhaseEnlistment.</b> С&nbsp;помощью экземпляра этого типа управляющий ресурсами может передать информацию управляющему транзакциями о&nbsp;результатах своей работы при использовании упрощенной схемы (однофазной фиксации).

=== Ограничения программных распределенных транзакций и альтернативы ===

Краткое исследование мнений, встречающихся в интернете, показывает, что во&nbsp;многих областях распределенные транзакции выходят из&nbsp;моды. Посмотрите, например, на&nbsp;[https://habr.com/company/flant/blog/347518/#comment_10640160 этот ехидный комментарий]. Основной объект критики, о&nbsp;котором вкратце сказано [https://habr.com/company/nixsolutions/blog/321686/ здесь],&nbsp;— это синхронная (блокирующая) природа распределенных транзакций. Если пользователь отправил запрос, во&nbsp;время обработки которого была организована распределенная транзакция, то&nbsp;он&nbsp;получит ответ только после того, как (успешно или с ошибкой) закончат работу все подсистемы, включенные в&nbsp;транзакцию. При этом есть подкрепленное исследованиями мнение, что протокол двухфазной фиксации показывает плохую производительность, особенно с&nbsp;ростом числа вовлеченных в&nbsp;транзакцию подсистем, о&nbsp;чем упоминается, например, в&nbsp;[https://habr.com/company/avito/blog/426101/ этой публикации на&nbsp;«Хабре»].

Если создатель системы предпочитает вернуть ответ пользователю как можно скорее, отложив согласование данных на&nbsp;потом, то&nbsp;ему больше подойдет какое-нибудь другое решение. В&nbsp;контексте теоремы Брюера ([https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP теоремы CAP]) можно сказать, что распределенные транзакции подходят для случаев, когда согласованность данных (Consistency) важнее доступности (Availability).

Существуют и&nbsp;другие практические ограничения на&nbsp;использование программных распределенных транзакций. Например, опытным путем было установлено, что распределенные транзакции по&nbsp;протоколу OleTx не&nbsp;должны пересекать сетевые домены. Во&nbsp;всяком случае, долгие попытки заставить их&nbsp;работать не&nbsp;увенчались успехом. Кроме того, было выявлено, что&nbsp;взаимодействие между несколькими экземплярами Oracle Database (распределенных транзакций СУБД) накладывает серьезные ограничения на&nbsp;применимость программных распределенных транзакций (опять&nbsp;же не&nbsp;удалось завести).

Какие есть альтернативы распределенным транзакциям? Сначала надо сказать, что вообще без&nbsp;технических транзакций (обычных, не&nbsp;распределенных) будет обойтись очень сложно. В&nbsp;системе наверняка будут процессы, которые могут временно нарушить целостность данных, и&nbsp;потребуется каким-то образом обеспечить надзор за&nbsp;такими процессами. Точно так&nbsp;же и&nbsp;в&nbsp;терминах предметной области может возникнуть понятие, включающее процесс, реализующийся совокупностью процессов в&nbsp;разных технических системах, который должен начинаться и&nbsp;заканчиваться в&nbsp;области целостных данных.

Переходя к&nbsp;альтернативам распределенных транзакций, можно отметить решения на&nbsp;основе служб сообщений, например RabbitMQ и&nbsp;Apache Kafka. [https://habr.com/company/nixsolutions/blog/322214/ В&nbsp;этой публикации на&nbsp;«Хабре»] рассматривается четыре таких решения:

1) подсистема публикует сообщение, на основе которого происходит и&nbsp;запись в&nbsp;БД, и&nbsp;уведомление других подсистем;

2) подсистема пишет в&nbsp;БД, а&nbsp;уведомления других подсистем формируются на&nbsp;основе журнала транзакций БД (Transaction Log Tailing);

3) подсистема ведет в&nbsp;БД как таблицы сущностей, так и&nbsp;таблицы сообщений для внешних подсистем;

4) сущности в&nbsp;БД однозначно представляются очередью записей об&nbsp;их&nbsp;создании и&nbsp;изменениях (Event Sourcing).

Еще одна альтернатива&nbsp;— шаблон «Сага». Он&nbsp;предполагает каскад подсистем со&nbsp;своими локальными транзакциями. По&nbsp;завершении работы каждая система вызывает следующую (либо самостоятельно, либо при помощи координатора). Для каждой транзакции имеется соответствующая отменяющая транзакция, и&nbsp;подсистема может вместо передачи управления дальше, наоборот, инициировать отмену изменений, сделанных ранее предыдущими подсистемами. На&nbsp;«Хабре» есть несколько хороших статей о&nbsp;шаблоне «Сага». К&nbsp;примеру, в&nbsp;[https://habr.com/company/avito/blog/426101/ этой публикации] приводятся общие сведения о&nbsp;поддержании принципов ACID в&nbsp;микрослужбах, а&nbsp;в&nbsp;[https://habr.com/company/oleg-bunin/blog/418235/ этой статье] подробно рассматривается пример внедрения шаблона «Сага» с&nbsp;координатором.

В&nbsp;нашей компании в&nbsp;некоторых продуктах успешно используются программные распределенные транзакции через WCF, но&nbsp;бывают и&nbsp;другие варианты. Однажды, когда мы&nbsp;пытались подружить новую систему с&nbsp;распределенными транзакциями, у&nbsp;нас возникло много проблем, включая столкновение с&nbsp;описанными выше ограничениями и&nbsp;параллельные неприятности с&nbsp;обновлением программной инфраструктуры. Поэтому в&nbsp;условиях дефицита ресурсов на&nbsp;обкатывание другого капитального решения мы&nbsp;применили следующую тактику. Вызываемая сторона фиксирует изменения в&nbsp;любом случае, но&nbsp;отмечает, что они находятся в&nbsp;состоянии черновика, поэтому эти изменения пока не&nbsp;влияют на&nbsp;работу вызываемой системы. Потом уже вызывающая сторона при&nbsp;завершении своей работы через распределенную транзакцию СУБД активизирует изменения, сделанные вызываемой системой. Таким образом, вместо программных распределенных транзакций мы&nbsp;воспользовались распределенными транзакциями СУБД, которые в&nbsp;данном случае оказались гораздо надежнее.

=== Так это есть в .NET Core? ===

В .NET Core (и&nbsp;даже в&nbsp;.NET Standard) есть все необходимые типы для организации транзакций и&nbsp;создания своего управляющего ресурсами. К&nbsp;сожалению, в&nbsp;.NET Core у&nbsp;транзакций на&nbsp;основе <code>System.Transactions</code> есть серьезное ограничение: они работают только с&nbsp;протоколом Lightweight. Например, если в&nbsp;коде используется два долговечных управляющих ресурсами, то&nbsp;во&nbsp;время выполнения среда выбросит исключение, как только будет произведено обращение ко&nbsp;второму управляющему.

Дело в&nbsp;том, что .NET Core стараются делать независимым от&nbsp;операционной системы, поэтому завязка на&nbsp;такие управляющие транзакциями, как KTM и&nbsp;MSDTC, исключается, а&nbsp;именно они и&nbsp;нужны для&nbsp;поддержания транзакций с&nbsp;указанными свойствами. Возможно, будет реализовано подключение управляющих транзакциями в&nbsp;виде плагинов, но&nbsp;пока что это вилами по&nbsp;воде писано, поэтому рассчитывать на&nbsp;промышленное применение распределенных транзакций в&nbsp;.NET Core пока нельзя.

На&nbsp;опыте можно убедиться в&nbsp;различиях распределенных транзакций в&nbsp;.NET Framework и&nbsp;в&nbsp;.NET Core, написав одинаковый код, скомпилировав и&nbsp;запустив его на&nbsp;разных платформах. Ниже приведен пример такого кода, вызывающего последовательно SQL Server и&nbsp;Oracle Database. Готовые для сборки проекты [https://github.com/CUSTIS-public/NetDistributedTransactionsExample находятся на&nbsp;GitHub].
<code-csharp>private static void Main(string[] args) {
    using (var scope = new System.Transactions.TransactionScope(System.Transactions.TransactionScopeOption.Required)) {
        MsSqlServer();
        Oracle();

        scope.Complete();
    }
}

private static void Oracle() {
    using (var conn = new Oracle.ManagedDataAccess.Client.OracleConnection("User Id=some_user;Password=some_password;Data Source=some_db")) {
        conn.Open();
        using (var cmd = conn.CreateCommand()) {
            cmd.CommandText = "update t_hello set id_hello = 2 where id_hello = 1";
            cmd.ExecuteNonQuery();
        }
        conn.Close();
    }
}

private static void MsSqlServer() {
    var builder = new System.Data.SqlClient.SqlConnectionStringBuilder {
        DataSource = "some_computer\\some_db",
        UserID = "some_user",
        Password = "some_password",
        InitialCatalog = "some_scheme",
        Enlist = true,
    };

    using (var conn = new System.Data.SqlClient.SqlConnection(builder.ConnectionString)) {
        conn.Open();
        using (var cmd = conn.CreateCommand()) {
            cmd.CommandText = "update t_hello set id_hello = 2 where id_hello = 1";
            cmd.ExecuteNonQuery();
        }
        conn.Close();
    }
}</code-csharp>

Запуск примера для&nbsp;.NET Core заканчивается ошибкой. От&nbsp;порядка вызова СУБД зависят место и&nbsp;тип выбрасываемого исключения, но&nbsp;в&nbsp;любом случае это исключение свидетельствует о&nbsp;недопустимой транзакционной операции. Запуск примера для&nbsp;.NET Framework заканчивается успешно, если в&nbsp;это время работает MSDTC; при этом в&nbsp;графическом интерфейсе MSDTC можно наблюдать регистрацию распределенной транзакции.

=== Распределенные транзакции и WCF ===

Windows Communication Foundation (WCF)&nbsp;&mdash; это программный каркас мира .NET, предназначенный для&nbsp;организации и&nbsp;вызова сетевых служб. По&nbsp;сравнению с&nbsp;более модными подходами REST и&nbsp;ASP.NET Web API он&nbsp;обладает своими достоинствами и&nbsp;недостатками. WCF очень хорошо дружит с&nbsp;транзакциями .NET, и&nbsp;в&nbsp;мире .NET Framework его удобно использовать для&nbsp;организации транзакций, распределенных между клиентом и&nbsp;службой.

В&nbsp;.NET Core эта технология работает только со&nbsp;стороны клиента, то&nbsp;есть создать службу нельзя, а&nbsp;можно только обратиться к&nbsp;уже существующей. Это, однако, не&nbsp;слишком важно, потому что, как сказано выше, с&nbsp;распределенными транзакциями в&nbsp;.NET Core дела вообще обстоят не&nbsp;очень хорошо.

==== Как устроен WCF ====

Для&nbsp;читателей, мало знакомых с&nbsp;WCF, дадим здесь самую краткую справочную информацию о&nbsp;том, что&nbsp;же представляет собой эта технология на&nbsp;практике. Контекст&nbsp;&mdash; две информационные системы, называемые клиентом и&nbsp;службой. Клиент во&nbsp;время выполнения обращается к&nbsp;другой информационной системе, поддерживающей интересующую клиента службу, и&nbsp;требует выполнить некоторую операцию. Потом управление возвращается клиенту.

Чтобы создать службу на&nbsp;WCF, обычно надо написать интерфейс, описывающий контракт создаваемой службы, и&nbsp;реализующий этот интерфейс класс. Класс и&nbsp;интерфейс размечаются особыми атрибутами WCF, выделяющими их&nbsp;среди остальных типов, и&nbsp;задают некоторые детали поведения во&nbsp;время обнаружения и&nbsp;вызова службы. Эти типы обертываются во&nbsp;что-то, работающее в&nbsp;виде сервера (например, в&nbsp;DLL, на&nbsp;которую натравливают IIS), и&nbsp;дополняются конфигурационным файлом (есть варианты), где указаны подробности реализации службы. После запуска к&nbsp;службе можно обращаться, например, по&nbsp;сетевому адресу; в&nbsp;интернет-обозревателе можно посмотреть контракты, которые реализует запрошенная служба.

Программист, желающий обратиться к&nbsp;существующей службе WCF, использует консольную утилиту или&nbsp;встроенный в&nbsp;среду разработки графический интерфейс, чтобы по&nbsp;имеющемуся адресу службы сформировать типы на&nbsp;языке&nbsp;C# (или&nbsp;на&nbsp;другом поддерживаемом языке), соответствующие контрактам службы. Файл с&nbsp;полученными типами включается в&nbsp;проект клиентского приложения, и&nbsp;после этого программист пользуется теми&nbsp;же терминами, что&nbsp;содержатся в&nbsp;интерфейсе службы, наслаждаясь благами прогресса (статической типизацией). Кроме этого, в&nbsp;конфигурационном файле клиента указываются технические характеристики вызываемой службы (возможна настройка и&nbsp;в&nbsp;коде, без&nbsp;конфигурационного файла).

WCF поддерживает разные виды транспорта, шифрования и&nbsp;иных более тонких технических параметров. Большинство из&nbsp;них объединяются понятием &laquo;привязка&raquo; (Binding). Есть три важных параметра службы WCF:

1) адрес, по&nbsp;которому она доступна;

2) привязка;

3) контракт (интерфейсы).

Все эти параметры устанавливаются в&nbsp;конфигурационных файлах службы и&nbsp;клиента.

В нашей компании WCF (и&nbsp;с&nbsp;распределенными транзакциями, и&nbsp;без&nbsp;них) широко используется во внедренных продуктах, однако, учитывая веяния моды, его использование в&nbsp;новых продуктах пока что находится под&nbsp;вопросом.

==== Как завести распределенные транзакции в WCF ====

Чтобы завести в&nbsp;WCF транзакции на&nbsp;основе <code>System.Transactions</code>, программисту нужно расставить в&nbsp;коде несколько атрибутов, убедиться, что используемые привязки поддерживают распределенные транзакции, на&nbsp;клиенте и&nbsp;в&nbsp;службе написано <code>transactionFlow=&quot;true&quot;</code> и&nbsp;что на&nbsp;всех задействованных компьютерах запущен подходящий управляющий транзакциями (скорее всего, это будет MSDTC).

Привязки, поддерживающие распределенные транзакции: NetTcpBinding, NetNamedPipeBinding, WSHttpBinding, WSDualHttpBinding и&nbsp;WSFederationHttpBinding.

Метод (операцию) интерфейса службы надо пометить атрибутом <code>System.ServiceModel.TransactionFlowAttribute</code>. Тогда при&nbsp;определенных параметрах атрибута и&nbsp;при&nbsp;установке параметра <code>TransactionScopeRequired</code> атрибута <code>System.ServiceModel.OperationBehaviorAttribute</code> транзакция будет распределяться между клиентом и&nbsp;службой. Кроме того, по&nbsp;умолчанию считается, что служба голосует за&nbsp;фиксацию транзакции, если только во&nbsp;время выполнения не&nbsp;было выброшено исключение. Чтобы поменять это поведение, надо установить соответствующее значение параметра <code>TransactionAutoComplete</code> атрибута <code>System.ServiceModel.OperationBehaviorAttribute</code>.

Ниже приведен код простейшей службы WCF, поддерживающей распределенные транзакции. Очевидно, что он отличается от&nbsp;кода обычной службы только использованием атрибута <code>System.ServiceModel.TransactionFlow</code> и&nbsp;специальной настройкой атрибута <code>System.ServiceModel.OperationBehavior</code>.
<code-csharp>[System.ServiceModel.ServiceContract]
public interface IMyService
{
    [System.ServiceModel.OperationContract]
    [System.ServiceModel.TransactionFlow(System.ServiceModel.TransactionFlowOption.Mandatory)]
    int DoSomething(string input);
}

public class MyService : IMyService
{
    [System.ServiceModel.OperationBehavior(TransactionScopeRequired = true)]
    [System.ServiceModel.TransactionFlow(System.ServiceModel.TransactionFlowOption.Mandatory)]
    public int DoSomething(string input)
    {
        if (input == null)
            throw new System.ArgumentNullException(nameof(input));
        return input.Length;
    }
}</code-csharp>

Конфигурация WCF для этой службы может быть, например, следующей.
<code-csharp><system.serviceModel>
    <services>
        <service name="WcfWithTransactionsExample.MyService" behaviorConfiguration="serviceBehavior">
            <endpoint address="" binding="wsHttpBinding" bindingConfiguration="mainWsBinding" contract="WcfWithTransactionsExample.IMyService"/>
            <endpoint address="mex" contract="IMetadataExchange" binding="mexHttpBinding"/>
        </service>
    </services>
    <bindings>
        <wsHttpBinding>
            <binding name="mainWsBinding" maxReceivedMessageSize="209715200" maxBufferPoolSize="209715200" transactionFlow="true" closeTimeout="00:10:00"
            openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
                <security mode="None"/>
                <readerQuotas maxArrayLength="209715200" maxStringContentLength="209715200"/>
            </binding>
        </wsHttpBinding>
    </bindings>
</system.serviceModel></code-csharp>

Обратите внимание на то, что используется привязка типа WSHttpBinding и атрибут <code>transactionFlow="true"</code>.

=== TL;DR по разделу ===

Распределенные транзакции включают несколько управляющих ресурсами, и&nbsp;все изменения должны либо фиксироваться, либо откатываться. Некоторые современные СУБД реализуют распределенные транзакции, которые представляют удобный механизм связи нескольких БД. Программные (реализуемые не&nbsp;в&nbsp;СУБД) распределенные транзакции могут включать разные комбинации управляющих ресурсами на&nbsp;разных компьютерах под управлением разных операционных систем, но&nbsp;они имеют ограничения, которые нужно учесть перед тем, как полагаться на&nbsp;них. Современной альтернативой распределенным транзакциям являются решения на&nbsp;основе службы сообщений. В&nbsp;.NET Core распределенные транзакции пока что не&nbsp;поддерживаются.

WCF&nbsp;&mdash; это один из&nbsp;стандартных и&nbsp;проверенных инструментов создания и&nbsp;обращения к&nbsp;службам в&nbsp;мире .NET, поддерживающий несколько видов транспорта и&nbsp;шифрования. WCF очень близко дружит с&nbsp;распределенными транзакциями на&nbsp;основе <code>System.Transactions</code>. Настройка распределенных транзакций для&nbsp;WCF заключается в&nbsp;разметке кода несколькими атрибутами и&nbsp;в&nbsp;добавлении пары слов в&nbsp;конфигурационных файлах службы и&nbsp;клиента. Не&nbsp;все привязки WCF поддерживают распределенные транзакции. Кроме того, очевидно, транзакции в&nbsp;WCF имеют те&nbsp;же ограничения, что и&nbsp;без использования WCF. Платформа .NET Core пока что позволяет только обращаться к&nbsp;службам на&nbsp;WCF, а&nbsp;не&nbsp;создавать&nbsp;их.

== Заключение-шпаргалка ==

Эта публикация представляет собой обзор основ программных транзакций .NET. Некоторые выводы относительно тенденций в&nbsp;программных транзакциях можно найти в&nbsp;разделах, посвященных применимости и&nbsp;ограничениям обсуждаемых предметов, а&nbsp;в&nbsp;заключении собраны основные тезисы публикации. Предполагаю, что их&nbsp;можно использовать в&nbsp;качестве шпаргалки при рассмотрении программных транзакций как одного из&nbsp;вариантов реализации технической системы или для освежения в&nbsp;памяти соответствующей информации.

<b>Транзакции (предметной области, СУБД, программные)</b>. Требования предметной области иногда формулируют в&nbsp;виде транзакций&nbsp;&mdash; операций, которые, начинаясь в&nbsp;области целостных данных, по&nbsp;завершении (в&nbsp;том числе и&nbsp;неудачном) должны приходить также в&nbsp;область целостных данных (возможно, уже другую). Эти требования обычно реализуются в&nbsp;виде системных транзакций. Классическим примером транзакции является перевод денег между двумя счетами, состоящий из&nbsp;двух неделимых операций&nbsp;&mdash; снятия денег с&nbsp;одного счета и&nbsp;зачисления на&nbsp;другой. Кроме известных всем транзакций, реализуемых средствами СУБД, существуют и&nbsp;программные транзакции, например в&nbsp;мире .NET. Управляющие ресурсами&nbsp;&mdash; это программные компоненты, знающие о&nbsp;существовании таких транзакций и&nbsp;имеющие возможность включаться в&nbsp;них, то&nbsp;есть фиксировать или откатывать сделанные изменения. Управляющие ресурсами получают инструкции о&nbsp;фиксации и&nbsp;откате изменений от&nbsp;управляющего транзакциями, составляющего основу инфраструктуры <code>System.Transactions</code>.

<b>Долговечные и&nbsp;непостоянные управляющие ресурсами.</b> Долговечные управляющие ресурсами поддерживают восстановление данных после системного сбоя. Драйверы СУБД для&nbsp;.NET как раз обычно предлагают такую функциональность. Непостоянные управляющие ресурсами <b>не</b>&nbsp;поддерживают восстановление после сбоя. Программную транзакционную память&nbsp;&mdash; способ управления объектами в&nbsp;оперативной памяти&nbsp;&mdash; можно рассматривать как пример непостоянного управляющего ресурсами.

<b>Транзакции и&nbsp;управляющие ресурсами .NET.</b> Программист .NET пользуется программными транзакциями и&nbsp;создает собственные управляющие ресурсами с&nbsp;помощью типов из&nbsp;пространства имен <code>System.Transactions</code>. Эта инфраструктура позволяет использовать транзакции различной вложенности и&nbsp;изоляции (с&nbsp;известными ограничениями). Использование транзакций&nbsp;&mdash; дело не&nbsp;сложное, и&nbsp;заключается оно в&nbsp;обертывании кода в&nbsp;блок <code>using</code> с&nbsp;определенными характеристиками. Однако включаемые таким образом в&nbsp;транзакцию управляющие ресурсами должны поддерживать требуемую функциональность со&nbsp;своей стороны. Использование в транзакции разнородных управляющих ресурсами или использование одного управляющего разными способами может автоматически превратить транзакцию в распределённую.

<b>Распределенные транзакции (СУБД, программные).</b> Распределенная транзакция охватывает несколько подсистем, изменения в&nbsp;которых должны быть синхронизированы, то&nbsp;есть они либо фиксируются все вместе, либо откатываются. Распределенные транзакции реализованы в&nbsp;некоторых современных СУБД. Программные распределенные транзакции (это уже не&nbsp;те, которые реализуются СУБД) накладывают дополнительные ограничения на&nbsp;взаимодействующие процессы и&nbsp;платформы. Распределенные транзакции постепенно выходят из&nbsp;моды, уступая решениям на&nbsp;основе служб сообщений. Чтобы превратить обычную транзакцию в&nbsp;распределенную, программисту почти ничего не&nbsp;надо делать: при включении в&nbsp;транзакцию управляющего ресурсами с&nbsp;определенными характеристиками во&nbsp;время выполнения управляющий транзакциями автоматически сделает все, что нужно. Обычные программные транзакции доступны в&nbsp;.NET Core и&nbsp;.NET Standard, а&nbsp;распределенные&nbsp;&mdash; не&nbsp;доступны.

<b>Распределенные транзакции через WCF.</b> WCF&nbsp;&mdash; это один из&nbsp;стандартных для .NET инструментариев создания и&nbsp;вызова служб, поддерживающий в&nbsp;том числе и&nbsp;стандартизированные протоколы. Другими словами, к&nbsp;определенным образом сконфигурированным службам WCF можно обращаться из&nbsp;любого приложения, не&nbsp;только .NET или&nbsp;Windows. Чтобы создать распределенную транзакцию поверх WCF, нужно разметить типы, составляющие службу, дополнительными атрибутами и&nbsp;внести минимальные изменения в&nbsp;конфигурационные файлы службы и&nbsp;клиента. В&nbsp;.NET Core и&nbsp;.NET Standard нельзя создавать службы WCF, но&nbsp;можно создавать клиенты WCF.

== Полезные ссылки ==

[https://github.com/CUSTIS-public/NetDistributedTransactionsExample Пример для проверки System.Transactions на GitHub]

'''Основные понятия'''

[https://ru.wikipedia.org/wiki/ACID ACID] (русская «Википедия»)

[https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/committing-a-transaction-in-single-phase-and-multi-phase Алгоритм двухфазной фиксации] (документация Microsoft)

[https://msdn.microsoft.com/en-us/library/cc229955.aspx Однофазная фиксация] (документация Microsoft)

[https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C Программная транзакционная память] (русская «Википедия»)

[https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP Теорема Брюера] (русская «Википедия»)

[https://en.wikipedia.org/wiki/Three-phase_commit_protocol Трехфазная фиксация] (английская «Википедия»)

'''Стандарты и конкретные реализации'''

[http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf Стандарт распределенных транзакций X/Open XA] (документ The Open Group)

[https://ru.wikipedia.org/wiki/Java_Transaction_API Java Transaction API] (русская «Википедия»)

[https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_tp Описание транзакций в объектной БД Cache] (сайт компании InterSystems)

'''Материалы о .NET'''

[http://fukyo-it.blogspot.com/2012/02/truly-understanding-net-transactions.html Подробное описание транзакций .NET] (сборник личных журналов Tech Blog Collection)

[https://habr.com/post/115480/ Подробное руководство по работе с TransactionScope] («Хабр»)

[https://docs.microsoft.com/en-us/dotnet/framework/data/transactions/optimization-spc-and-promotable-spn Описание участника транзакции, поддерживающего продвижение и однофазную фиксацию] (документация Microsoft)

[https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md Что нового в .NET Standard 2.0] (репозиторий .NET Standard на GitHub)

[https://yarfullstack.com/post/2017-03/isolation-level-and-connection-pool/ Проблемы с пулом соединений и уровнями изоляции транзакции] (журнал YarFullStack)

'''Материалы о микрослужбах'''

[https://habr.com/company/nixsolutions/blog/321686/ Вводная статья по разработке транзакционных микрослужб] («Хабр»)

[https://habr.com/company/nixsolutions/blog/322214/ Принципы и примеры разработки транзакционных микрослужб] («Хабр»)

[https://habr.com/company/avito/blog/426101/ Обзорная статья по шаблону «Сага» и целостности данных в микрослужбах] («Хабр»)

[https://habr.com/company/oleg-bunin/blog/418235/ Подробная статья о применении шаблона «Сага» с координатором] («Хабр»)

[https://habr.com/company/flant/blog/347518/#comment_10640160 Ехидный комментарий о распределенных транзакциях] («Хабр»)




[[Категория:Георгий Минашин (Статьи)]]
[[Категория:Хабрахабр (Публикации)]]
[[Категория:2018 год (Статьи)]]
[[Категория:CustisWikiToLib]]