Persistence Settings for In-Memory Flow Instances

The persistence settings for the components comprising a business flow determine when the flow, state, and audit data is persisted to the cache, or the database. This also impacts the flow instance data that appears in Enterprise Manager Fusion Middleware Control.

Table 13-6 lists the various persistence settings and their impact on flow, state, audit, and sensor data.

Table 13-6 Persistence Settings for In-Memory Flow Instances

Completion Persist Policy Description Businesss Flow Instances in Enterprise Manager

Immediate The flow trace, BPEL audit trace, and flow instance state data is always persisted to the database. The behavior is the same as if in-memory SOA is not enabled.

Deferred

Completion Persist Policy	Description	Businesss Flow Instances in Enterprise Manager
Immediate	The flow trace, BPEL audit trace, and flow instance state data is always persisted to the database.	The behavior is the same as if in-memory SOA is not enabled.
Deferred	All flow, audit, and state data is initially persisted to the Coherence cache. A separate write-behind thread performs a deferred write of the cache to the database. The write-behind thread wakes up at periodic intervals, the default being 5 minutes. The number of database round-trips is reduced, and only coalesced data is written to the database every time the write-behind thread wakes up.	You should see all flow instances in Enterprise Manager Fusion Middleware Control. However, as the write-behind thread writes to the database at deferred intervals, the flow data updates happen at intervals determined by the write-behind thread. Enterprise Manager reads its data from the database.
Faulted	The flow trace, BPEL audit trace, and flow instance state data is not persisted for successful executions. If the flow encounters a fault, then all data is persisted to the database. Once the flow has been recovered, all flow data is purged. If a component reaches dehydration point, then the state data is persisted to the Coherence cache. For long running flows that span write delay intervals, the write-behind thread does temporarily persist the state of running instances to the database. These are purged after the instances complete execution.	For flows that use the `faulted` completion persist policy, you should not see flow instances in Enterprise Manager Fusion Middleware Control, except for faulted flow instances. Note that long-running flow instances might transiently show up in Enterprise Manager, as and when they are persisted to the database by the write-behind thread. However, this data is purged after the flow instance completes.

All flow, audit, and state data is initially persisted to the Coherence cache. A separate write-behind thread performs a deferred write of the cache to the database. The write-behind thread wakes up at periodic intervals, the default being 5 minutes.

The number of database round-trips is reduced, and only coalesced data is written to the database every time the write-behind thread wakes up.

You should see all flow instances in Enterprise Manager Fusion Middleware Control.

However, as the write-behind thread writes to the database at deferred intervals, the flow data updates happen at intervals determined by the write-behind thread. Enterprise Manager reads its data from the database.

Faulted

The flow trace, BPEL audit trace, and flow instance state data is not persisted for successful executions. If the flow encounters a fault, then all data is persisted to the database. Once the flow has been recovered, all flow data is purged.

If a component reaches dehydration point, then the state data is persisted to the Coherence cache.

For long running flows that span write delay intervals, the write-behind thread does temporarily persist the state of running instances to the database. These are purged after the instances complete execution.

For flows that use the faulted completion persist policy, you should not see flow instances in Enterprise Manager Fusion Middleware Control, except for faulted flow instances.

Note that long-running flow instances might transiently show up in Enterprise Manager, as and when they are persisted to the database by the write-behind thread. However, this data is purged after the flow instance completes.

The string values immediate, deferred, and faulted are case-insensitive.

As business flows can span composites and components, persistence for a flow comprising components with different persistence settings is determined by the components that persist. So, even if one component is configured to persist to the database, then all components in the flow will persist to the database.

For example, if you have a BPEL component with persistence set to deferred and another BPEL component in the same flow has persistence set to immediate, then the immediate setting overrides the deferred setting, and all flow instance state and flow audit trace data is persisted immediately to the database. Similarly, if you have all components set to faulted, but even one component is set to deferred, then the persistence setting defaults to deferred and flow state and audit data is persisted.

Note:

The component state and component audit trace is persisted based on the persistence policy applied to the component. The flow instance state and flow audit trace is determined by the override rule. So, immediate overrides deferred overrides faulted.
Sensor data is persisted per the flow data. If flow is persisted to the database, then sensor data is also persisted to the database.

Write Delay for In-Memory Flows

The default interval used by the write-delay thread is 5 minutes. This means that the data is copied from the cache to the database every 5 minutes.

If you have a strong case to modify this, say, if most of your BPEL processes complete in 6 minutes, as opposed to 5 minutes, and you wish to tweak the write-delay in order to reduce your database writes, you can set the following server start argument for your SOA server:

-Dsoa.cache.writebehindDelay=6m

The Oracle WebLogic Remote Console can be used to set server start arguments.