The effect of deliveryPersistPolicy

Oracle BPEL has a number of knobs you can tweak to improve performance, one of the easiest tweaks is the deliveryPersistPolicy parameter.

This parameter determines whether the delivery messages, entering BPEL, are persisted. That is when you call a BPEL process an row is inserted into the BPEL repository, and response is given to the client. After a short time worker threads are activated to process the request.

<Picture of request , message table , threads >
If you look at your BPEL statistics page you'll see that this process can take a couple of hundred ms' so lets assume that your process is synchronous and can be repeated, do you want it to be persisted???

Fortunatly this is one of the knobs you can tweak to improve performance here..


deliveryPersistPolicy has three valid values


on
Client thread stores message in the database
Worker threads pick up the message and deliver it to the BPEL instance
This approach is a "Send and forget" approach, with the guarantee that once its submitted it will get processed

off
No database logging is done, the message is stored in memory cache

If the server crashes during the processing then the request will be lost.

off.immediate (since 10.1.3.1)
In this scenario the message isnt saved at all, and the request is passed directly to the BPEL instance.
"Send and Wait" approach
Great for Synchronous processes that can be repeated.

This parameter can be set in the BPEL Console parameters screen.