Global Transaction is governed by the following parameters –
- the message exchange pattern,
- the datasource and
- the composite properties for the particular components viz. bpel.config.
In a single global transaction, any fault within the Composite will result in a complete rollback of all transactions. However, if there are boundaries then in the event of a fault within the global transaction, local transactions will be committed while the global transaction is rollbacked.
If fault happens in the partnerlink and it is not handled then the local transaction is rollbacked and a FabricInvocationExceptions is thrown back to the parent BPEL process. If fault happens in the partnerlink and it is handled then the local transaction is committed.
How to create local transactions or boundaries:
The boundaries are defined in the composite.xml of the component properties of the called process. The exact properties are dependant on the Message Exchange Pattern(MEP) of the called Component:
1. If MEP is Sync Request Response, then transaction=requiresNew
2. If MEP is Async Request Response, then transaction=RequiresNew, oneWayDeliveryPolicy=sync
3. If MEP is One Way, then transaction=RequiresNew, oneWayDeliveryPolicy=sync
Note -The transaction parameters are only defined for BPEL Components. So, if you do want to create local transactions, you would have to embed adapters in bpel processes. I do not understand why this limitation should be there.
Transaction Behaviour of BPEL process
You only must set a new
transaction property on the BPEL component being called (known as the callee process). You add
bpel.config.transaction into a BPEL process service component section in the
composite.xml file (note the required prefix of
bpel.config.). This property configures the transaction behavior for BPEL instances with initiating calls.
There are two possible values:
new transaction is created) and
existing transaction is suspended).
What-if there is a another Receive activity
bpel.config.transaction property does not apply for midprocess receive activities. In those cases, another thread in another transaction is used to process the message. This is because correlation is needed and it is always done asynchronously.