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
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 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.
No comments:
Post a Comment