rss
SOATUBE
Oracle
Custom Search SOABYTE here

Friday, June 25, 2010

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:
<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
For more information refer: Oracle SOA Best Practices guide








1 comments:

Post a Comment

 
Blogger Profile