Oracle BPEL Process Manager Transaction Semantics

As with previous releases, Oracle BPEL Process Manager by default creates a new transaction on a request basis. That is, if a transaction exists, it is suspended, and a new transaction is created. Upon completion of the child (new) transaction, the master (suspended) transaction resumes.

However, if the request is asynchronous (that is, one-way), the transaction is either:

Inherited for insertion into the dehydration store (table dlv_message).
Enlisted transparently into the transaction (if one exists).

There is no message loss. Either the invocation message is inserted into the dehydration store for processing or the consumer is notified through a fault.

In Release 10.1.3.x, there were several properties to set on the consuming process (that is, on the partner link) and the providing process. This enabled you to chain an execution into a single global transaction. On the consuming side, you set transaction=participate on the partner link binding in the bpel.xml file. On the providing side, you set transaction=participate in the <configurations> section of bpel.xml.

In Releases 11g and 12c, you only must set a new transaction property on the BPEL component being called (known as the callee process). You add bpel.config.transaction as follows:

In the Create BPEL Process dialog for a new BPEL process.
In the BPEL process service component section in the composite.xml file of an existing BPEL process (note the required prefix of bpel.config.).

This property configures the transaction behavior for BPEL instances with initiating calls. If you must change this setting later, you can use the Property Inspector.

The following example provides details:

<component name="InternalWareHouseService" version="2.0">
    <implementation.bpel src="BPEL/InternalWareHouseService.bpel"/>
    <property name="bpel.config.transaction" type="xs:string"
many="false">required | requiresNew | notSupported " </property>
  </component>

Table 13-1 describes the required (the default value) and requiresNew values and summarizes the behavior of the BPEL instance based on the settings.

Table 13-1 bpel.config.transaction Property Behavior

For...	With bpel.config.transaction Set to required...	With bpel.config.transaction Set to requiresNew...
Request/response (initiating) invocations	The caller's transaction is joined (if there is one) or a new transaction is created (if there is not one).	A new transaction is always created and an existing transaction (if there is one) is suspended.
One-way initiating invocations in which `bpel.config.oneWayDeliveryPolicy` is set to `sync`.	Invoked messages are processed using the same thread in the same transaction.	A new transaction is always created and an existing transaction (if there is one) is suspended.

Note:

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.

For additional information about setting the bpel.config.transaction property, see How to Add a BPEL Process Service Component and How to Define Deployment Descriptor Properties in the Property Inspector.

The following sections describe the transaction and fault behavior of setting bpel.config.transaction to either required or requiresNew.