Tune BPEL Process Performance Via Persistence Settings

• deliveryPersistPolicy
• inMemoryOptimization
• completionPersistLevel
• completionPersistPolicy
• idempotent

One-way and two-way invocations

There are two types of invocations into a bpel instance: one-way operation and two-way operation.

* A one-way invocation is request only and has only the inbound message.
* A two-way invocation is a request and response operation. The caller thread blocks until a response is ready.

One-way invocation Two-way invocation
WSDL definition

< name="oneway">





< name="twoway">

BPEL activities

<receive operation="oneway" variable="in"/>



<receive operation="twoway" variable="in"/>
...
<reply operation="twoway" variable="out"/>

Through delivery service Request is saved in delivery service. Caller thread doesn't wait for the message to be delivered to the targeted instance. Request is delivered into engine and to the targeted BPEL instance. Caller thread is blocked until the response is ready.
synchronous and asynchronous processes

There are two types of BPEL processes in terms of dehydration.

* A synchronous process is a process that gets executed from start to end without dehydration in the middle. This is usually done within one j2ee transaction.
* An asynchronous process is a process that has one or more dehydration points in the course of the execution because of the BPEL activities like <receive>, <onMessage>, and <wait>. Process has to by dehydrated till the event being waited is ready. This kind of process is executed in multiple j2ee transactions because of DB commits of the process dehydration.

Note that the synchronicity of the process has nothing to do with the WSDL interface of the process. A synchrounous prcoess can be instantiated with either a one-way operation or a two-way operation. The same is true for an asynchrounous process.
Idempotent

An idempotent activity is an activity that can be retried, for example, the assign activity. A non-idempotent activity is an activity that can happen only once, for example, an invocation to a hotel booking web service. The engine saves the instance after a non-idempotent activity.
In-flight DB store

Over the life cycle of a BPEL instance, the instance with its current state of execution might be saved in database multiple times. There are two cases a a DB store will occur.

* When the instance is waiting for an event. It can be either an alarm or an invocation message. This happens when one of the following BPEL activities are being executed: wait, onAlarm, receive, and onMessage. When a BPEL instance is saved to DB in this case, the instance is also called being dehydrated. Later when the event happens (alarm expires or the message comes in), the instance is then read from the DB and resumes execution.
* After a non-idempotent activity. The reason we want to store the instance here is that if we want to retry the steps, we retry from the steps after the non-idempotent activity.

In terms of whether the instance is saved before it completes (normally or abnormally), BPEL instances are divided into two types: type-I and type-II. Type-I instances don't have in-flight instance saving, type-II instances have in-flight instance saving.
JTA transactions for two-way invocations

For two-way invocations, if the process being called is a type-I process, the engine honors the caller's JTA transaction (transaction flag the of operation is "support"). If the process being called is a type-II process, meaning there is possibly in-flight DB save going on, the engine will create a new transaction (transaction flag of the operation is "require new").

Tuning the performance with persistence properties
idempotent

By default, a BPEL invoke is an idempotent activity, meaning engine will not save the instance right after it. But for a remote invoke like a hotel booking invocation, you want the engine to save the instance right away so in case the instance fails on subsequent activities, the record of calling the service doesn't get removed. You can do this by setting the idempotent property in the partnerLinkBinding of the deployment descriptor.
idempotent
true (default) engine will not take action right after the activity
false engine will save the instacne right after the activity



This is an example of turning off the DB saving of the one-way invocation message.

<BPELSuitcase>
<BPELProcess src="Invoke.bpel" id="Invoke">
<partnerLinkBindings>

<partnerLinkBinding name="client">
<property name="wsdlLocation">Invoke.wsdl</property>

</partnerLinkBinding>
<partnerLinkBinding name="IncrementService">
<property name="wsdlLocation">

http://glennmi:9700/orabpel/default/IncrementService/IncrementService?wsdl
</property>
<property name="idempotent">false</property>
</partnerLinkBinding>
</partnerLinkBindings>
</BPELProcess>
</BPELSuitcase>

deliveryPersistPolicy

The deliveryPersistPolicy configuration property is used to turn on and off the DB persist of one-way invocation. This property only applies to one-way invocation and the default value is "on".
deliveryPersistPolicy
on (default) store one-way message in delivery service DB
off store one-way message in delivery cache only



One-way requests by default are saved in the delivery service database table. These requests are later picked up by engine worker threads and delivered to the targeted BPEL instances. In the case where performance is preferred over reliability, the saving of one-way messages in the DB can be skipped. The messages are kept in delivery service in memory cache.

Setting of this option can only be set in domain configuration. Domain config is available in OraBPEL console.

Notes: The one-way invocation messages are stored in delivery cache until they are delivered. If the rate the one-way messages are coming in is much higher than the rate that the engine delivers them, there is the risk that some of the messages get lost.

inMemoryOptimization

This property is used to indicate to the engine that this particular process is a type-I process and it doesn't have in-flight DB store. The engine will keep the instances of this process in memory during the course of execution. This property only applies to type-I process. Therefore, if it is detected that the process is possibly a type-II process, the compiler will throw exception.
inMemoryOptimization
false (defult) there is possible in-flight db saving
true there will be no in-flight db saving


completionPersistLevel

Currently a BPEL instance is saved in two tables after the instance is completed: cube_instance table and cube_scope. The cube_instance stores the header information of the instance like modification time, creator, etc.. The cube_scope stores the state of the instance like variable values, etc.. By default, both tables are used to store a completed instance.

The completionPersistLevel can be used to fine tune what part of the instance are used.
completionPersistLevel
all (defult) This is the default value, meaning the instance is saved in both cube_instance and cube_scope tables.
instanceHeader Only the header part of the instances are saved in cube_instance table. cube_scope table is not used.


The completionPersistLevel property can only be used when inMemoryOptimization is set to be true(type-I processes). For type-II processes, all the instance information has to be saved for it later be resurrected.

This is an example of turning off the DB saving of the one-way invocation message.

<BPELSuitcase>
<BPELProcess src="HelloWorld.bpel" id="HelloWorld">
...
<configurations>
<property name="inMemoryOptimization">true</property>

<property name="completionPersistLevel">instanceHeader</property>
</configurations>
</BPELProcess>
</BPELSuitcase>


completionPersistPolicy

This property can only be used when inMemoryOptimization is set to be true.
completionPersistPolicy
on (default) The completed instance will be saved normally.
deferred The completed instance will be saved, but with a different thread and in another transaction.
faulted Only the faulted instance will be saved.
off No instance of the this process wil be saved.

This is an example of turning off the DB saving of the one-way invocation message.

<BPELSuitcase>
<BPELProcess src="HelloWorld.bpel" id="HelloWorld">
...
<configurations>
<property name="inMemoryOptimization">true</property>

<property name="completionPersistPolicy">off</property>
</configurations>
</BPELProcess>
</BPELSuitcase>