Transaction Management

Working with Transactions in Oracle Bpel

Use bpelx: rollback and transaction=participate for ensuring transactionality across a BPEL process, on a case-by-case basis which needs transaction support across multiple BPEL processes.

a) Throw a bpelx:rollback fault within your flow:

<throw name="Throw" faultName="bpelx:rollback"/>

b) Specify transaction=participate on the partnerlink binding in bpel.xml on both provider and consumer side:

<property name="transaction">participate</property>

</partnerLinkBinding>

Use of idempotent property

This property is set for the partnerlink in bpel.xml. The default value of this property is true (expecpt for Recieve,pick,wait,reply)

True - Engine will not dehydrate right after invocation to this partner.

False - Engine will dehydrate right after invocation to this partner.

Use case:

When Oracle BPEL Server recovers after a crash, it retries the activities in the process instance. However, it should only retry the idempotent activities. Therefore, when Oracle BPEL Server encounters a nonidempotent activity, it

dehydrates it. This enables Oracle BPEL Server to memorize that this activity was performed once and is not performed again when Oracle BPEL Server recovers from a crash.

Use of nonBlockingInvoke property

This property is set for the partnerlink in bpel.xml. The default value of this property is false.

True - Engine will spawn a new thread to execute each invocation in the flow/flowN branch.

False - Engine will NOT spawn a new thread to execute each invocation in the flow/flowN branch.

Use Case:

Normally when executing a synchronous (two-way) invoke activity Oracle BPEL Server waits for the response from the endpoint before executing the following activity. This behavior can present problems when synchronous invoke activities are placed inside a flow activity, because Oracle BPEL Server executes the flow using pseudo-parallelism.

Incase of mutliple flow activities, this property can be used to spawn new threads for each invocation. A partner link property nonBlockingInvoke indicates whether BPEL would use multiple threads to execute invocation to this partner in Flow/Flown branches.

The table below summarises the transaction status when performing different activities:

Activity	Transaction Status in BPEL Process	Transaction Status in Target Process or Adapter
Receive	New Transaction	N/A
Receive with Property “transaction=participate”	Use Existing Transaction from Caller	N/A
Invoke Synchronous Process	Use Existing Transaction	New Transaction
Invoke Synchronous Process with Partner Link Property “transaction=participate”	Use Existing Transaction	Use Existing BPEL Transaction
Invoke Synchronous Process with Partner Link Property “idempotent=false”	New Transaction	New Transaction
Invoke Synchronous Process with Partner Link Property “nonBlockingInvoke=true”	New Transaction	New Transaction
Invoke Asynchronous Process	Use Existing Transaction	New Transaction
Invoke Asynchronous Process with Partner Link Property “transaction=participate”	Use Existing Transaction	New Transaction
Invoke Asynchronous Process with Partner Link Property “idempotent=false”	New Transaction	New Transaction

For more information refer: Oracle SOA Best Practices guide

Oracle Fusion Middleware

Main Menu

Friday, June 25, 2010