Database Reference
In-Depth Information
Managing the Dehydration Store
Until now you have been learning about common administration tasks involving
the MDS repository. The MDS maintains a small database footprint as it is simply
used to store application metadata, common reusable artifacts, and runtime con-
figuration changes. Another important schema that would require more frequent
monitoring and close administration is the [PREFIX]_SOAINFRA , which is used
to store instance and transactional data of all the composites being executed in
the infrastructure. This database schema is also referred to as the Dehydration
Store . Oracle SOA Suite 11g leverages the Dehydration Store database to main-
tain long-running processes and their current state information while they are ex-
ecuting over a period of time. Storing the process in a database preserves the
process and prevents any loss of state or reliability in case of a system shut down
or when a network problem occurs.
Configurations affecting the SOA Suite 11g
Dehydration Store
It is important to understand how the nature of a deployed composite affects what
is saved in the Dehydration Store. Business processes in general can be categor-
ized either as transient processes (short lived, request-response style synchron-
ous processes) or durable processes (long running asynchronous processes).
Transient processes do not incur any intermediate dehydration during their exe-
cution. Furthermore, the instances of a transient process do not leave a trace in
the system in the event of unhandled faults or system downtime. Also, instances
of transient processes cannot be saved in-flight whether they complete normally
or abnormally. On the other hand, durable processes can have one or more activ-
ities during execution that cause instances to dehydrate in the database. For ex-
ample, in a BPEL component, a few activities that cause this intermittent dehyd-
ration are Receive, Pick, Wait, Reply, and Checkpoint.
Instance data being saved to the Dehydration Store database depends upon sev-
eral factors such as the design of the process, the nature of its synchronicity, audit
and logging levels, persistence policies, whether the instance is being optimized
Search WWH ::




Custom Search