Transaction Subprocess

Транзакция успешна, если она не отменена и не прервана сбоем (hazard). Если транзакционный подпроцесс успешен, он покидается через исходящий поток (потоки) операций. Успешная транзакция может быть компенсирована, если позднее в процессе выбрасывается Compensation Event.

Примечание: так же, как и «обычные» встроенные подпроцессы, транзакционный подпроцесс может быть компенсирован после успешного завершения с помощью промежуточного выбрасывающего Compensation Event.

Транзакция отменяется, если исполнение достигает Cancel End Event. В этом случае все исполнения завершаются и удаляются. Затем единственное оставшееся исполнение устанавливается на Cancel Boundary Event, который запускает компенсацию. После завершения компенсации транзакционный подпроцесс покидается через исходящий поток (потоки) операций Cancel Boundary Event.

Транзакция завершается сбоем (hazard), если выбрасывается событие-ошибка, не пойманное в области видимости транзакционного подпроцесса. (Это также относится к случаю, когда ошибка ловится на границе транзакционного подпроцесса.) В этом случае компенсация не выполняется.

В то время как ACID-транзакция обычно кратковременна, BPMN-транзакция может занимать часы, дни или даже месяцы. (Рассмотрите случай, когда одна из активностей, сгруппированных транзакцией, — это User Task; как правило, люди реагируют дольше, чем приложения. Или, в другой ситуации, BPMN-транзакция может ожидать наступления некоторого бизнес-события, например того факта, что определённый заказ выполнен.) Такие операции обычно занимают значительно больше времени, чем обновление записи в базе данных или сохранение сообщения с помощью транзакционной очереди.

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

Поскольку BPMN-транзакция охватывает несколько ACID-транзакций, мы теряем ACID-свойства. Рассмотрим приведённый выше пример. Предположим, что операции «забронировать отель» и «списать с кредитной карты» выполняются в отдельных ACID-транзакциях. Предположим также, что активность «забронировать отель» успешна. Теперь у нас промежуточное несогласованное состояние, потому что мы выполнили бронирование отеля, но ещё не списали средства с кредитной карты. В ACID-транзакции мы тоже выполняли бы разные операции последовательно и поэтому тоже имели бы промежуточное несогласованное состояние. Разница здесь в том, что несогласованное состояние видно за пределами области видимости транзакции. Например, если бронирования делаются с помощью внешнего сервиса бронирования, другие стороны, использующие тот же сервис бронирования, могут уже видеть, что отель забронирован. Это означает, что при реализации бизнес-транзакций мы полностью теряем свойство изоляции (положим, мы обычно также ослабляем изоляцию при работе с ACID-транзакциями, чтобы обеспечить более высокий уровень параллелизма, но там у нас есть точечный контроль, и промежуточные несогласованности присутствуют лишь очень короткие промежутки времени).

BPMN-бизнес-транзакцию также нельзя откатить в традиционном смысле. Поскольку она охватывает несколько ACID-транзакций, некоторые из этих ACID-транзакций могут быть уже зафиксированы в момент отмены BPMN-транзакции. В этот момент их уже нельзя откатить.

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

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

Кроме того, поскольку транзакция может быть прервана в случае сбоя, сервис бронирования должен справляться с ситуацией, когда номер отеля забронирован, но оплата так и не была предпринята (так как транзакция была прервана). В этом случае сервис бронирования может выбрать стратегию, при которой номер отеля резервируется на максимальный срок, и, если к этому моменту оплата не получена, бронирование отменяется.