Working with Transactions SOA Suite 11g

A transaction manager is responsible for coordinating the operations in a transaction. If all

the operations are in the same resource, such as the same database, then the resource may

manage the transaction itself. If the transaction is spread across multiple resources, such as

the database and message queue, then an XA transaction manager is required to co-ordinate

the operations across different resources.

SOA Suite by default will use the XA transaction manager in the application server to coordinate

its transactions. When a message arrives in SOA Suite, an XA transaction is started.

Always have a clear plan of where you want transaction boundaries to occur. Determine if you want BPEL processes to be part of existing transactions or if you want to execute them within their own transaction. Transactions can be committed by using a dehydrate statement or by calling a non-idempotent service.

bpel.config.transaction property the with the value required to be set if you want to use the existing transaction.

bpel.config.transaction property the with the value requiredNew to be set if you want to start new transaction and suspend the existing transaction.

For example component property in composite.xml.

<component name="SampleProcess1" version="1.1">

<implementation.bpel src=" SampleProcess1.bpel"/>

<property name="bpel.config.transaction" many="false" type="xs:string">required</property>

</component>

To test it create a sample SOA application. In Jdeveloper 11.1.1.6  it asks you while creating the Sync Bpel process. By default it is set to required. But in previous version you need to set it manually.

Create a Bpel Process with  SampleProcess1 as shown below.

Create a DBAdpater named getLocalTransaction with execute pure SQL and provide query as

“ Select dbms_transaction.local_transaction_id from dual ”.

Create another Bpel Process with required value in transaction property.

Connect both bpel process with DBAdpater.

Composite should look like as shown below.

In SampleProcess1 Bpel Process invoke getLocalTransaction Db service to get LOCAL_TRANSACTION_ID and after that invoke sampleProcess2.

The SampleProcess1 should look as shown below

In SampleProcess2 invoke DB service to get LOCAL_TRANSACTION_ID.

The SampleProcess2 should look as shown below.

 

Deploy and test it.

First with the bpel.config.transaction set as required and in second time changed that property to requiredNew.

Check the LOCAL_TRANSACTION_ID in both the invocation it will be the same in the first case because both the process using the same transaction context. But it will be different in requiredNew because in this case it will suspend existing transaction and start new one in second bpel process.

***Synchronous BPEL processes that have the required transaction attribute should always leave the committing of the transaction to the caller. they should never force the committing of a transaction.***