Transaction in SOA 11g

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: required (new transaction is created) and requiresNew (existing transaction is suspended).

What-if there is a another Receive activity

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

Advertisements

3 comments

  1. You share interesting things here. I think that your page can go viral
    easily, but you must give it initial boost and i know how to
    do it, just type in google (with quotes) for – “mundillo traffic increase”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s