Режим длинных транзакций 4.3.0-
Каждый процесс имеет несколько точек управления (в простейшем случае одну). Точка управления аналогична потоку в любом языке программирования. Хотя о них можно думать как о выполняющихся параллельно, реально они выполняются последовательно.
Инициатором продвижения точки управления могут быть:
- пользователь или бот, выполняющий элемент Задание либо Мульти-Задание
- созревший элемент Таймер
- сообщение для элемента Получить сообщение
Т.е. элементами, состояние которых хранится в БД, являются: Задание, Таймер, Получить сообщение (также Параллельный шлюз в режиме ожидания точек управления по другим переходам). Все остальные элементы, расположенные между ними, выполняются в рамках транзакции, инициируемой из этих элементов. При ошибке в любом из них транзакция откатывается полностью к инициирующему элементу. При большом количестве элементов транзакции могут конфликтовать между собой (при попытке параллельного инициирования в рамках одного процесса).
Режим коротких транзакций (настраиваемый) 4.3.0+
В связи с проблемами:
- отката транзакции к инициирующему элементу в случае ошибки в процессе (например пользователь не может выполнить задание в случае ошибки в исключающем шлюзе)
- конфликте длинных транзакций (особенно при использовании элементов Подпроцесс, Мульти-Подпроцесс)
был реализован механизм, позволяющий уменьшить границы транзакций, настроив некоторые элементы так чтобы они выполнялись в новой транзакции. Этот механизм позволяет сделать инициирующим элементом любой элемент процесса, при этом передвигая точку управления автоматически (реализация на основе JMS).
Рассмотрим пример: Задание -> Исключающий шлюз (с ошибкой) -> Завершение.
В случае работы механизма по умолчанию пользователь не сможет выполнить Задание, т.к. ошибка в элементе Исключающий шлюз будет вызывать ошибку и откат транзакции к элементу Задание (пользователь при этом будет видеть на экране непонятную ошибку). Если же мы для элемента Исключающий шлюз настроим новую транзакцию — то пользователь успешно выполнит Задание (точка управления после коммита этой транзакции будет указывать на элемент Исключающий шлюз). А вот при последующем движении точки управления возникает ошибка, которая возвращает точку управления к элементу Исключающий шлюз. При этом пользователь доволен, администратор видит системную ошибку и устраняет её (например модификацией процесса либо предоставлением недостающих данных) и активирует процесс чтобы он прошёл далее.
Настройки для изменения границ транзакций 4.3.0+
В порядке убывания приоритета.
На уровне процесса настройки задаются в редакторе:
- в свойствах любого узла настройка Транзакция для выполнения может принимать значения: По умолчанию (не задано), Отдельная (Новая), Существующая. Применяется для этого элемента.
- в свойствах процесса настройка Транзакция для выполнения по умолчанию может принимать такие же значения, распространяется на все элементы этого процесса
На уровне сервера следующие настройки применяются если на уровне процесса они не заданы:
- process.execution.node.async.NodeType использовать новую транзакцию для выполнения узла определённого типа по умолчанию, где NodeType является значением из перечисления
- process.execution.node.async.default использовать новую транзакцию для выполнения всех узлов по умолчанию
Кроме того, в случае коротких транзакций необходимо выполнить настройку для очереди JMS. Внести в файл Standalone.xml.
<address-setting match="jms.queue.nodeAsyncExecution"> <redelivery-delay>3000</redelivery-delay> <max-delivery-attempts>3</max-delivery-attempts> </address-setting>
где max-delivery-attempts — это максимальное количество попыток, которые предпринимаются каждые redelivery-delay мс
