Dividing Transactions
If a protocol message points to some resource potentially containing a big amount of data (typically batch processing via file requests), a single transaction cannot perform all the work and create all the corresponding service orders. This transaction must be split into several smaller transactions.
The first reason for splitting the transaction is that memory can quickly get exhausted if thousands of operations are performed in the transaction.
The second reason for splitting the transaction is that contentions exist on the service order queue. On one side the flow controller pumps service orders ; on the other side, the client adapter enqueues service orders. Having short transactions on the client adapter side, reduces these contentions.
In the best case, transaction management is handled by the protocol adapter itself. NETMAN is a very good example.
In the worst case, the client adapter has to manage the transactions. A simple utility to include this feature in a protocol message flow is to deploy a provcautil::Iterator module.