Oracle SOA 11g 11. 1.1.6 Performance Tuning of BPEL Processes
BPEL Properties Set Inside a Composite
The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.
- Receive activity
- OnMessage branch in a pick activity
- OnAlarm branch in a pick activity
- Wait activity
- Reply activity
- checkPoint() within a <bpelx:exec> activity
inMemoryOptimizationThis property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
This property has the following values:
- False (default): instances are persisted completely and recorded in the dehydration store database.
- True: The completionPersist policy is used to determine persistence behavior.
completionPersistPolicyThis property configures how the instance data is saved. It can only be set at the BPEL component level. The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).
|On (default)||The completed instance is saved normally|
|Deferred||The completed instance is saved, but with a different thread and in another transaction.|
|Faulted||Only the faulted instances are saved.|
Note: When an unhandled fault occurs, regardless of these flags, audit information of the instance is persisted within
|Off||No instances of this process are saved.|
<component name="BPELProcess"> <implementation.bpel src="BPELProcess.bpel" /> <property name="bpel.config.completionPersistPolicy">faulted</property> <property name="bpel.config.inMemoryOptimization">true</property> ... </component>
bpel.config.auditLevelproperty to an appropriate value in the composite.xml file of your SOA project as shown in the example below:
<component name="BPELProcess"> <implementation.bpel src="BPELProcess.bpel" /> <property name="bpel.config.auditLevel">Off</property> </component>
|Inherit||Inherits the audit level from infrastructure level.|
|Off||No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.|
|Minimal||All events are logged; however, no audit details (variable content) are logged.|
|Error||Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.|
|Production||All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.|
|Development||All events are logged; all audit details for all activities are logged.|
Partner Link Property
- False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When
idempotentis set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
- 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. 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.
- True: Oracle BPEL Server spawns a new thread to execute the invocation.
- False (default): Oracle BPEL Server executes the invoke activity in the single process thread.
- True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid then
bpelx:invalidVariablesrun time BPEL Fault is thrown. This overrides the domain level
- False (default): Disables XML validation.
- If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
- If the design of the process allows it, avoid the activities listed above.