Regulating the unit of work size for batches

Units of work for batches can quickly grow out of proportion. To ensure large numbers of transactions within batches can be processed, and in order to maximize parallel processing, it is important to design the FSM in a way that avoids very large database units of work when batch sizes are large.

One way to achieve this is to avoid batch events that trigger state changes on all transactions within the batch. Instead, generate one event for each transaction (set to 'render as message') so that the transitions run in smaller units of work. Make sure that these events aggregate on the transaction context. As a general rule, always look out for transitions on an FSM whose event filter, object filter, or both are based on a foreign key ID to an object that is related to the object being transitioned.

Potential large unit of work transition is an example of an FSM with a single batch level event that causes state change and action on all contained transactions. This is a transaction object FSM, but the event filter uses the BATCH_ID of the transactions (the foreign key to the parent batch object).

Small unit of work transition is a better example where the action that raises E_BatchValid also raises E_TxnBatchvalid for each transaction in the batch. The transaction FSM transition can then occur on the transaction level event with filters applied on the transaction ID. The size of this unit of work will depend on the aggregation threshold on the TRANSACTION context..