Two or more parallel invoke activities are in a flow activity. You want to know why the invoke activities run sequentially.
- To achieve real parallelism, each path must be in a separate transaction. Set the "transactional behavior" attribute of all of the parallel invoke activities to "commit before" or "requires own".
- If you are using Oracle, Derby, Informing, or Cloudscape as the database system, navigation transactions for parallel branches in a process instance are serialized; that is, they cannot be run in parallel. This is because the locks on database entities are not as granular as those for DB2 databases. However, services that are triggered asynchronously by such parallel branches still run in parallel; it is only the process navigation that is serialized for these database systems.
Because only one navigation transaction is processed at a time in Business Process Execution Language (BPEL) processes, and when using the databases above, the goal is to minimize transactional boundaries when designing parallel paths in BPEL processes. You achieve this by doing the following:
- Setting the transactional behavior to "commit after" after a BPEL invoke activity (if possible).
- Using asynchronous invocations because the transaction is committed as soon as the message arrives in the target destination.