ProcessTransactions

The Behaviour of Transactions When Executing Processes on the Server

RunaWFE Free Workflow System (BPMS) Version 4.5.0

© 2003 - 2015, Consulting Group Runa

© 2015 - 2024, "Process Technologies" Ltd, this document is available under GNU FDL license. RunaWFE Free is an open source system distributed under a LGPL license (http://www.gnu.org/licenses/lgpl.html).

# Description - pre 4.3.0

Every process has several tokens (in the simplest case – one). A token is like a thread in any programming language. Though you can think of them as parallel operations, in fact they are carried out sequentially.

The requester of a token forwarding may be:

• a user or a bot executing a Task or a Multi-task element
• an expired Timer element
• a message for a Receive message element

So, the elements, the states of which are stored in the database are Task, Timer and Receive message (also Parallel gateway when waiting for tokens through other transitions). All the other elements located between them are executed in line with the transaction requested by these elements. If an error occurs in any of them the transaction is rolled back entirely to the element that has requested it. If the amount of elements is large, the transactions may conflict with one another (on attempts of requesting them simultaneously within one process).

# Transaction boundary configuration in version 4.3.0 ^4.3.0+

Due to the following problems:

• transaction rollback to the requester element in case of an error in the process (a user can not carry out a task if an error occurred in an exclusive gateway).
• conflict of long transactions (especially when using Subprocess or Multi-Subprocess elements).

a mechanism was implemented, which allows to narrow the boundaries of transactions by configuring some elements so that they will be carried out in a new transaction. This mechanism allows to make any element of the process a requester however moving the token automatically (implementation is based on JMS).

Let us consider an example: Task → Exclusive gateway (failed) → End.

If the mechanism works by default, the user will not be able to carry out the Task as the error in the Exclusive gateway element will cause fail and rollback of the transaction to the task element (the user will see a strange error on the screen). But if we set up a new transaction for the Exclusive gateway element, the user will successfully carry out the Task (after committing this transaction the token will point at the Exclusive gateway element). But upon the next forwarding of the token an error occurs which rolls the token back to the Exclusive gateway element. However, the user is satisfied, the administrator sees a system error and fixes it (for example by modifying the process or by providing the required data) and activates the process to make it go forward.

# Settings for transaction boundary configuration

in order of priority.

On the process level the configurations are set up in the developer studio:

• In the properties of any node the Transaction for execution configuration may take on the following values: Default (not set), New or Shared. Applied to the current element.
• In the process properties the Default transaction for execution configuration may take on the same values. Applied to all the elements of the process.

On the server level the configurations are applied if they are not set on the process level:

• process.execution.node.async.NodeType – use a New transaction to execute a node of a certain type by default, where NodeType is a value from the list.
• process.execution.node.async.default – use a new transactions to carry out all the nodes by default.