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.***
