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:
<partnerLinkBinding name="...">
<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 |
0 comments:
Post a Comment