How to make a Durable process a Transient one

First of all we need to understand what is a durable process and what is a transient process.A transient process is one that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities.In opposite way a durable process is one which has dehydration point.Dehydration point are called as the rollback point in a process that is if a system is executing a process and in middle the server just crashes the process will be rolledback to the last dehydration point passed in the process.That is the reason why this process is called durable.

select count(*) from cube_instance;




We will achieve this by creating a simple asynchronous bpel process which by default will dehydrate the instance in the database.Then we will use some bpel performacne properties to change this default bahaviour

We will be essentially using two properties

completionPersistPolicy and inMemoryOptimization

As per Oracle documentation

inMemoryOptimization
inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.

Values:

This property has the following values:

*

False (default): instances are persisted completely and recorded in the dehydration store database.
*

True: The completionPersist policy is used to determine persistence behavior.

13.3.1.2 completionPersistPolicy

This property configures how the instance data is saved. It can only be set at the BPEL component level. The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).
Value Description
On (default) The completed instance is saved normally
Deferred The completed instance is saved, but with a different thread and in another transaction.
Faulted Only the faulted instances are saved.
Off No instances of this process are saved.

For more information these properties check the following link


Now we will create a simple asynchoronous process which will assing the input variable to the out put variable and deploy it in a server.Once you deploy the process go to em console and create a instance of this process.

before testing the service.

Open up a command console and log in to sql

Log in with dev_soainfra user and corresponding passoword.

ONce you log in to the schema issue a statement

select count(*) from cube_instance;

this will fetch you some result.

Now run the instance from em console and again issue the same command in sql

you will find an increase in the number of count in cube_instance table because
the data is dehydrate into data base.

IF you don't want this behaviour and want that the instance should not be

dehydrated to data base.you need to use these properties.

SO open you project in jdeveloper.

Open your composite.xml and go to source view.

Look for the "component.name" filed once you find the field

Just mention the two properties in the configuration ,in my case it looks like

this

<component name="BPELInstance" version="1.1">
<implementation.bpel src="BPELInstance.bpel"/>
<property name="configuration.inMemoryOptimization">true</property>
<property name="configuration.completionPersistPolicy">off</property>
</component>

Now save the changes and redeploy the process.Now again create an instance and you

will not find an increase in the number of cube_instance.This property is often

used to achieve improved performance.