Understanding Dehydration in BPEL

 

Dehydration in Oracle BPEL

Over the life cycle of a BPEL instance, the instance with its current state of execution may be saved in a database. When a BPEL instance is saved to a database, the instance is also known as being dehydrated. The database where the BPEL instance is saved is called a dehydration store.

Once a BPEL instance is dehydrated, Oracle BPEL Server can off load it from the memory of Oracle BPEL Server. When a certain event occurs, such as the arrival of a message or the expiration of a timer, Oracle BPEL Server locates and loads the pertinent BPEL instance from the dehydration store back into the memory of Oracle BPEL Server and resumes the execution of the process instance. Dehydrating BPEL instances offers reliability. If Oracle BPEL Server crashes in the middle of executing a process, the instance can be recovered automatically, programmatically, or manually from the dehydrated states. When Oracle BPEL Server resumes the execution of the process instance, it resumes from the last dehydration point, which is the last state of the instance that Oracle BPEL Server saves to the dehydration store.

Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callbacks. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.

Transient vs. durable BPEL processes

 Transient process — Oracle BPEL Server dehydrates the process instance only once at the end of the process. When a host crashes in the middle of running the process instance, the instances are not visible from Oracle BPEL Control.

 Durable process — Oracle BPEL Server dehydrates the process instance in-flight at all midprocess breakpoint and non-idempotent activities, plus the end of the process. When the server crashes, this process instance appears in Oracle BPEL Control up to the last dehydration point (breakpoint activity) once the server restarts. If the server crashes before the process instance reaches the first midprocess breakpoint activity, the instance is not visible in Oracle BPEL Control after the server restarts.

   eg:

• Receive activity
• OnMessage branch in a pick activity
• OnAlarm branch in a pick activity
• Wait activity

  There are three cases in which dehydration occurs:

1> When the BPEL instance encounters a mid-process breakpoint activity (not including the initial receive)

     That is where an existing BPEL instance must wait for an event, which can be either a timer expiration or message arrival. When the event occurs (the alarm expires or the message arrives), the instance is loaded from the dehydration store and execution is resumed. This type of dehydration occurs only in durable processes, which have mid-process breakpoint activities. A transient process does not have any midprocess breakpoint activities.

2> When the BPEL instance encounters a non-idempotent activity

    When Oracle BPEL Server recovers after a crash, it re tries the activities in the process instance. However, it should only retry the idempotent activities. Therefore, when Oracle BPEL Server encounters a nonidempotent activity, it dehydrates it. This enables Oracle BPEL Server to memorize that this activity was performed once and is not performed again when Oracle BPEL Server recovers from a crash.(check for idempotent activity below)

3>  When the BPEL instance finishes

      At the end of the BPEL process, Oracle BPEL Server saves the process instance to the dehydration store, unless you explicitly configure it not to do so. This happens to both durable and transient processes. For transient processes, the end of the process is the only point where the process instance is saved. This is because a transient process does not have any mid-process breakpoint activities and nonidempotent activities where the in-flight dehydration can occur
.

 Idempotent BPEL Property
A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.
If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.
When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.
Setting this parameter to true can significantly improve throughput. However, as mentioned previously, you must ensure that the partner's service can be safely retried in the case of a server failure. Some examples of where this property can be set to true are read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.
Values
This property has the following values:
•false: activity is dehydrated immediately after execution and recorded in the dehydration store
•true (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed.

Dehydration occurs at different times for different BPEL processes.

BPEL processes are mainly two kinds: transient and durable.

Transient process: These are the kind that does not have any break activity or mid receive activity in their design. Dehydration process occurs at the end of the process. If the BPEL process crashes before finishing, then the instance is lost. We will not find the traces of this process in the dehydration store. To java folks, this is very much similar to a transient variable. When explicitly declared as transient the variable will not be persisted with the object state and cannot be serialized.

Durable process: BPEL processes of this kind are dehydrated on the fly when a breakpoint or non-idempotent activity is encountered. In the event of a server crash, the BPEL process restarts from the last dehydration point.

A very important detail is that if a BPEL process fails without reaching a dehydration point then the instance will not show up on the BPEL console. This instance never gets stored to the database.

Dehydration can be forced in several ways
· adding check points
· by setting the idempotent property to false
· adding mid receive activity – if the process needs to wait for an event


Below are the BPEL properties that determine how much to data to be saved to the database during dehydration process.

inMemoryOptimization: only applicable to transient processes. When set to true, the bpel process is only maintained in the memory until finished. Dehydration does not occur on this kind of processes.

completionPersistLevel: controls what type of data is saved after process completion. Property can only be set on transient bpel processes and works when inMemoryOptimization is set to true. When this property is set to “all”, it saves all the final variables, audit data and work item data. This causes the database to increase largely in size. When this property is set to “instanceHeader”, only the instance metadata gets stored to the database.

completionPersistPolicy: controls if and when to persist the instance. When this property is set to “faulted”, only the faulted instances are saved to the database. This setting has a good impact on the database. When set to “on”, all the instances are saved. When set to “off”, nothing is saved. When set to “deferred”, finished instances are saved with a different thread and in another transaction. If server fails, some instances may not be saved.

The above three properties are used together. If used properly, this can reduce the database growth as well as increase the throughput.

Idempotent: applicable to bpel activities. When set to false, the bpel process is dehydrated after this activity. If the server crashes after this, the activity is not executed as it is already recorded in the database as executed.