Branches in flow, flowN, and forEach activities are executed serially in a single thread (that is, the Nth branch is executed only after N-1 execution has completed). Execution is not completely parallel. This is because the branches do not execute in concurrent threads in this mode. Instead, one thread starts executing a flow branch until it reaches a blocking activity (for example, an synchronous invoke). At this point, a new thread is created that starts executing the other branch, and the process continues. This creates the impression that the flow branches are executing in parallel. In this mode, however, if the flow branches do not define a blocking activity, the branches still execute serially.

This design is intended for several reasons:

• To prevent you from accidentally spawning too many threads and overloading the system, single threading is the default method. However, you can tune threads in other places, such as adapter polling threads, BPEL process service engine threads, and Oracle WebLogic Server work managers.

• The BPEL process specification does not provide a mechanism to ensure the thread safety of BPEL variables (that is, a lack of a synchronized qualifier such as in Java), which is necessary for true multithreaded programming.

• The implication of transaction rollbacks in one of the branches is undefined.

To achieve pseudo-parallelism, you can configure invoke activities to be nonblocking with the nonBlockingInvoke deployment descriptor property. When this property is set to true, the process manager creates a new thread to perform each branch's invoke activity in parallel.

For more information about the nonBlockingInvoke property, see How to Define Deployment Descriptor Properties in the Property Inspector.