Scribd
Upload
29 views2 pages

Dehydration Store

Dehydration is the process of storing the current state of a long-running or asynchronous BPEL process in database tables to free up server resources. This allows the process to be resumed if the server crashes. There are two types of processes: transient processes, which are only dehydrated at completion, and durable processes, which are dehydrated at multiple points including after receive, pick, and wait activities as well as completion. Durable processes allow instances to be recovered if the server fails at any point during execution.

Uploaded by

raghavi_26
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
29 views2 pages

Dehydration Store

Dehydration is the process of storing the current state of a long-running or asynchronous BPEL process in database tables to free up server resources. This allows the process to be resumed if the server crashes. There are two types of processes: transient processes, which are only dehydrated at completion, and durable processes, which are dehydrated at multiple points including after receive, pick, and wait activities as well as completion. Durable processes allow instances to be recovered if the server fails at any point during execution.

Uploaded by

raghavi_26
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Dehydration Store

Dehydration

Storing the current status of the BPEL process(i.e. long running process, asynchronous
process) into the database tables is known as dehydration
SOA_INFRA schema is the dehydration store which contains tables to hold the meta
data of the process.

Why Dehydration

Long running process or processes waiting for response consumes memory and CPU
While waiting for the response the bpel engine can store the process, thus freeing up
server resources.
Over the life cycle of the BPEL instance, the instance with the current state of execution
may be saved in database.

Process gets dehydrated only at the end of the process.


Using Dehydrate activity we can explicitly dehydrate process state if required.

Asynchronous Process

Automatically dehydrated the process based on the activities used.


Types of BPEL Process
When and how dehydration occurs differs based on process types. Based on the dehydration
we can categorize process in to 2 categories

Transient Process: Oracle BPEL server dehydrates the process instance only at the end
of the process. If server crashes in middle of the running process instance, the instances
will not be visible in EM. The synchronous process you design in Oracle JDeveloper is an
example of a transient process.
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.This process type incurs one or more dehydration points in the
database during execution because of the following activities:
Receive activity
OnMessage branch in a pick activity
OnAlarm branch in a pick activity
Wait activity

Instances of durable processes can be saved in-flight (whether they complete normally or abnormally).
These processes are typically long-living and initiated through a one-way invocation.

You might also like