Database Reference
In-Depth Information
Tuning composite applications
The tuning covered in this chapter will give your SOA Infrastructure the perform-
ance boost that is required by the composite applications running on it. However,
there are composite application design time considerations that should be ad-
dressed, otherwise improperly designed composites may degrade the overall per-
formance regardless of how tuned your infrastructure is. As an administrator, hav-
ing fundamental knowledge of these design time considerations is recommended.
BPEL persistence
Over the life cycle of a BPEL instance, the instance with its current state of exe-
cution might be saved in the database multiple times. This can incur considerable
overhead. There are roughly two cases leading to an instance getting stored in
the database:
•
When the instance is waiting for an event (wait, onAlarm, pick, and so on), the
instance is dehydrated to the database. Later when the event happens (alarm
expires or the message comes in), the instance is rehydrated and resumes
execution.
•
When an instance encounters a non-idempotent activity. The instance in this
case is persisted in the database as it may have to be retried after the non-
idempotent activity.
At the composite level, there are three persistence properties that can be tuned
to optimize the process performance. Proactively, you should also try to set the
instance persistence levels at design time itself. They are:
•
inMemoryOptimization:
This property is used to indicate to the engine
that the process does not need to save in-flight instance in the database. The
engine will keep the instances of this process in memory during the course of
execution. The default value of this is
false
and can be overridden to true
to optimize transient processes.
