Thursday, June 4, 2009

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.


Anonymous said...

For a "durable"\asynchronous process is there anyway to set a timeout at the SOA BPEL level?

For instance if process doesn't receive a response for 2 hours, just kill it rather than retry.

Anonymous said...


What about durable synchronous processes in clustered environment? Are they supported?

Marek Jodlowski

ismail said...

We can set a time with add alarm activity