If there are concurrent running transactions in an instance (if you've forked the workflow) and the actions run by these transactions are creating read/write conflicts in the context. They may be seen as transaction serialization errors in the log. To solve a conflict, the CoreMedia Workflow Server automatically repeats the conflicting transactions. This means that even already executed actions are repeated, too.
Since there is a complete rollback of the transactions, the actions cannot determine if they are run repeatedly. Try to avoid the conflicts arising from this under all circumstances or you may experience problems with your workflow. Stick to the following rules:
Write actions that are fault-tolerant and can handle multiple repeated executions.
Split your critical sections into several tasks to isolate the non-repeatable actions from the actions creating the conflicts.
Note that, even if you follow these rules, an action may be executed repeatedly in the unlikely event of a CoreMedia Workflow Server crash. During the next restart, all failed transactions are repeated to reach a consistent state. This may repeat the execution of your action, too.
If an action throws any exception, its task instance will be escalated immediately:
Side effects on the instances context will become persistent, there is no rollback of the transaction.
If you are running two actions and the second one fails, the success and result variables of the first action will keep their values.
Upon a retry, these variables can be used by the first action's guard to avoid repeated execution.
Exceptions within the RunActionTimerHandler actions will have no effect other
than the handler failing.
 |  |  |
 |