BPEL Threading model in SOA 11g
|ThreadPool Name||Property value|
|Invoke Thread Pool (for asynchronous invocations) or Dispatcher Invoke Thread||dspInvokeThreads
|Total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.|
|Engine Thread Pool (i.e. for callback execution) or Dispatcher Thread Engine||dspEngineThreads
|Total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.|
|Dispatcher System Thread Pool||dspSystemThreads
|Total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.|
|Dispatcher Maximum Request Depth||dspMaxRequestDepth
|Sets the maximum number of in-memory activities to process within the same request. After processing an activity request, Oracle BPEL Process Manager attempts to process as many subsequent activities as possible without jeopardizing the validity of the request. Once the activity processing chain has reached this depth, the instance is dehydrated and the next activity is performed in a separate transaction. If the request depth is too large, the total request time can exceed the application server transaction time out limit.This process is applicable to durable processes.|
|Property Name||Property value|
|Delivery messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.|
|Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered. The system can become overloaded (messages become backlogged in the scheduled queue) and you may receive out-of-memory errors. If the rate at which one-way messages arrive is much higher than the rate at which they are delivered, or if the server fails, messages can be lost.|
|Direct invocation occurs on the same thread. The scheduling of messages in the invoke queue is bypassed, and the BPEL instance is invoked synchronously. In some cases this setting can improve database performance. Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.|
By default, incoming requests are saved in the delivery service database table dlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process.
This property persists delivery messages and is applicable to durable processes. If the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost.