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 |
1 comments:
Thanks a lot! You made a new blog entry to answer my question; I really appreciate your time and effort.
RESTful Web Services Corporate TRaining
RESTful Web Services Training In Chennai
Java Projects for Engineering Students of Computer Science
Project Centers in Chennai For CSE
Post a Comment