Transient vs. durable BPEL processes

As a general practice, it is better to design your BPEL processes as transient instead of durable if performance is a concern. Note that this may not always be possible due to the nature of your process, but keep the following points in mind.

The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.

Transient Processes

Transient processes do not incur dehydration during their process execution. If an executing process experiences an unhandled fault or the server crashes, instances of a transient process do not leave a trace in the system. Thus, these instances cannot be saved in-flight regardless if they complete normally or abnormally. Transient processes are typically short-lived, request-response style processes. Synchronous processes are examples of transient processes.

Durable Processes

Durable processes incur one or more dehydration points in the database during execution. Dehydration is triggered by one of the following activities:

• Receive activity
• OnMessage branch in a pick activity
• OnAlarm branch in a pick activity
• Wait activity
• Reply activity
• checkPoint() within a <bpelx:exec> activity

Durable processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized.

What should you do?

• If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
• If the design of the process allows it, avoid the activities listed above.

Any time your process is dehydrated to the dehydration store, this naturally impacts the performance of the process, and becomes a concern particularly in high volume environments.

===========================================================

Transient and Durable Process

Most of us who are working in Oracle SOA has came across a common question many times,
what is transient and durable process in SOA.

As we know oracle soa uses dehydration store to store all the details of a process which has been executed, may it be a successful execution or may it be a failure each and every details are stored in the the soa dehydration store.
A process will be called a Transient process whose state  is not stored in soa dehydration store or in tern we can say it is an in-memory execution. Any process which are not stored in the dehydration store we can call it a Transient process.

A process will be called a durable process which has its state stored in the soa dehydration store. By default all the BPEL process are durable process and its instances are stored in the dehydration tables.

Oracle SOA gives us flexibility to make any process transient forcefully by setting few properties.
These properties are bpel.config.inMemoryOptimization and bpel.config.completionPersistPolicy.
By setting these properties in tandem we can forcefully make a durable process transient.


Though there is some catch in this. As we know oracle SOA BPEL engine executes a process depending upon its message exchange pattern, if the process is synchronous then dehydration happens at the end of the execution or else if the process is asynchronous then the dehydration happens wherever the process encounters a dehydration point/activity ( wait , receive , pick , onAlarm , dehydrate).
We can make a synchronous process transient by setting above properties in the composite.xml provided the synchronous process does not have any dehydration points within its flow or else these properties won't work.

below is a snap of how to set these properties in the composite xml

<component name="BPELProcess" version="1.1">

   <property name="bpel.config.inMemoryOptimization" type="xs:string" many="false">true</property>

   <property name="bpel.config.completionPersistPolicy" type="xs:string" many="false">off</property>

</component>

Once these properties are set as shown above we will not be able to see the audit trail of this process from the em as the process is a transient process.


=======================================================================

What is diff b/w Transient and Durable?

Transient process:
1.Synchronous process is the example of transient process- hence no dehydration activity.
2.No mid process breakpoint activities (Receive, onMessage, onAlarm, Wait)
3.No non-idempotent invoke And No non-blocking invoke
Durable process:
1.Long Running Process Has mid process breakpoint activities (Receive, onMessage, onAlarm, Wait)
2.Has non-idempotent invoke or Has non-blocking invoke


=========================================================================