Transaction and Fault Propagation Semantics in BPEL Processes

13.1 Introduction to Transaction Semantics

Transaction semantics in Release 12c enable you to use the underlying Java Transaction API (JTA) infrastructure used in the execution of components. This section describes transaction semantics for Oracle BPEL Process Manager.

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

13.1.1.1 BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to requiresNew

In Table 13-2, the BPELCaller process calls the BPELCallee process. The BPELCallee process has the property bpel.config.transaction set to requiresNew. Table 13-2 describes fault propagation and transaction behavior when bpel.config.transaction is set to this value.

Table 13-2 BPELCaller Calls BPELCallee That Has bpel.config.transaction Set to requiresNew

If The BPELCallee...	Then The BPELCallee Transaction...	And The BPELCaller...
Replies with a fault (that is, it uses `<reply>`).	Is saved.	Gets the fault and can catch it.
Throws a fault that is not handled (that is, it uses `<throw>`).	Is rolled back.	Gets the fault and can catch it.
Replies back with a fault (FaultOne), and then throws a fault (FaultTwo).	Is rolled back.	Gets FaultTwo.
Throws a `bpelx:rollback` fault (that is, it uses `<throw>`).	Is rolled back.	Gets a remote fault.

13.1.1.2 BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to required

In Table 13-3, the BPELCaller process calls the BPELCallee process. The BPELCallee process has the property bpel.config.transaction set to required. Table 13-3 describes fault propagation and transaction behavior when bpel.config.transaction is set to this value.

Table 13-3 BPELCaller Calls BPELCallee That Has bpel.config.transaction Set to required

If The BPELCallee...	Then The BPELCaller...
Replies with a fault (that is, it uses `<reply>`).	Gets the fault and can catch it. The BPELCaller owns the transaction. Therefore, if it catches it, the transaction is committed. If the BPELCaller does not handle it, a global rollback occurs.
Throws a fault (that is, it uses `<throw>`).	Gets the fault and can catch it.
Replies back with a fault (FaultOne), and then throws a fault (FaultTwo).	Gets FaultTwo.
Throws (that is, it uses `<throw>`) a `bpelx:rollback` fault.	Gets its transaction rolled back; there is no way to catch it. This fault cannot be handled.

As an example, assume you create two synchronous processes (BPELMaster and BPELChild) that each use the same database adapter reference to insert the same record (and therefore, causes a permission key (PK) violation). The xADatasourceName is set for both.

Without bpel.config.transaction set, after the fault occurs, and it is not handled, BPELChild is rolled back. If BPELMaster has a catch block, its transaction is committed. Therefore, you end up with the record from BPELMaster in the database.

If you do not catch the fault in BPELMaster as well, you get a second rollback (however, in two different transactions).

If bpel.config.transaction is set to required for the same test case and no fault handlers are in place, the entire transaction is rolled back based on BPELMaster's unhandled fault.

If you add a fault handler in BPELMaster to catch the fault from BPELChild and throw a rollback fault, the transaction is globally rolled back.

This feature enables you to control transaction boundaries and model end-to-end transactional flows (if your sources and targets are also transactional).

13.2 Introduction to Execution of One-Way Invocations

A one-way invocation (with a possible callback) is typically exposed in a WSDL file as shown in the following example:

<wsdl:operation name="process">
        <wsdl:input message="client:OrderProcessorRequestMessage"/>
    </wsdl:operation>

This causes the BPEL process service engine to split the execution into two parts:

For the first part, and always inside the caller transaction, the insertion into the dlv_message table of the dehydration store occurs (in release 10.1.3.x, it was inserted into the inv_message table).
For the second part, the transaction and the new thread execute the work items, and a new instance is created.

This has several advantages in terms of scalability, because the service engine's thread pool (invoker threads) executes when a thread is available. However, the disadvantage is that there is no guarantee that it executes immediately.

If you require a synchronous-type call based on a one-way operation, then you can use the onewayDeliveryPolicy property, which is similar to the deliveryPersistPolicy property of release 10.1.3.x.

Specify bpel.config.oneWayDeliveryPolicy as follows:

In the Create BPEL Process dialog for a new BPEL process.
In the BPEL process service component section of the composite.xml file for an existing BPEL process.

If this value is not set in composite.xml, the value for oneWayDeliveryPolicy in the System MBean Browser in Oracle Enterprise Manager Fusion Middleware Control is used. The following values are possible.

async.persist: Messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.
async.cache: Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, consider this setting. When set to async.cache, if the rate at which one-way messages arrive is much higher than the rate at which they are delivered, or if the server fails, messages can be lost. In addition, the system can become overloaded (messages become backlogged in the scheduled queue) and you can receive out-of-memory errors. Consult your own use case scenarios to determine if this setting is appropriate.

When you set oneWayDeliveryPolicy to async.cache in high availability environments, invoke and callback messages in the middle of execution at the time of a server crash may be lost or duplicated. Server failover is not supported for async.cache.
sync: Direct invocation occurs on the same thread. The scheduling of messages in the invoke queue is bypassed, and the BPEL instance is invoked synchronously. In some cases this setting can improve database performance.

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

Table 13-4 describes the behavior when the main process calls the subprocess asynchronously. Table 13-4 is based on the use cases described in BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to requiresNew and BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to required.

Table 13-4 Main Process Calls the Subprocess Asynchronously

If...	If The Subprocess Throws Any Fault...	If The Subprocess Throws a bpelx:rollback...
`onewayDeliveryPolicy=async.persist` (The BPELCallee process runs in a separate thread/transaction.)	The BPELCaller does not get a response because the message is saved in the delivery service. The BPELCallee transaction is rolled back if the fault is not handled.	The BPELCaller does not get a response because the message is saved in the delivery service. The BPELCallee instance is rolled back on the unhandled fault.
`onewayDeliveryPolicy=sync` and `transaction=requiresNew` (The BPELCallee runs in the same thread, but a different transaction.)	The BPELCaller receives a `FabricInvocationException`. The BPELCallee transaction rolls back if the fault is not handled.	The BPELCaller receives a `FabricInvocationException`. The BPELCallee transaction is rolled back.
`onewayDeliveryPolicy=sync` and `transaction=required` (The BPELCallee runs in the same thread and the same transaction.)	The BPELCallee faulted. The BPELCaller receives a `FabricInvocationException`. The BPELCaller has a chance to handle the fault.	The whole transaction is rolled back.
`onewayDeliveryPolicy=async.cache` and `transaction=requiresNew` or `transaction=required`	The BPELCaller does not get a response because the caller thread returns before the request is handled. The BPELCallee transaction is rolled back if the fault is not handled. The message is lost because it is not saved in the database.	The BPELCaller does not get a response because the caller thread returns before the request is handled. The BPELCallee transaction is rolled back if the fault is not handled. The message is lost because it is not saved in the database.

13.3 Executing a Business Process Without a Transaction

You can execute a business process without the need for a transaction. A transaction is only used at the following points in the process execution:

At the dehydration point when the internal processing state must be stored in the back end data store.
When storing the audit trail or instance tracking-related data during process execution.

13.3.1 When Should I Use a BPEL Process Without a Transaction?

Executing a business process without a transaction is beneficial in scenarios similar to the following:

Assume you have a BPEL process in which a flowN activity spawns 2000 branches. Each branch invokes a remote synchronous web service that takes 500 ms to respond. Because the BPEL process service engine executes flowN branches individually in a single thread, processing all 2000 branches with each one invoking a synchronous web service takes close to 1000 seconds and the instance does not have access to the dehydration point during this processing. The transaction can extend for 1000 seconds and can time out (the default transaction timeout setting is 300 seconds). Everything can be performed directly in memory without the need for a transaction.
The duration of a transaction gets tied up with the life cycle of business process execution. For example, assume an asynchronous BPEL process includes a receive activity followed by an assign activity in which a complex XSL transformation performed on a large document takes 30 seconds. This is followed by a callback to the client. If executed in a transaction, the BPEL process service engine starts the transaction at the receive activity and holds a lock inside the database on the instance while the instance is executing.

As an alternative, all activities can be performed in memory and discarded if an error occurs. A transaction is not required because a database update does not occur during instance execution. A transaction is only required once instance execution reaches the dehydration point, where the BPEL process service engine updates the instance state, and so on.
Assume a BPEL process invokes another service or partner link that is synchronous and participates in a BPEL process service engine's JTA transaction (for example, if a BPEL process invokes the TaskServiceBean, which has TransactionAttribute=REQUIRED, and there is a TaskServiceBean time out and the transaction is roll backed). Even the BPEL process service engine's JTA transaction gets rolled back and the BPEL process is unable to handle the error from the TaskServiceBean.
If a business process invokes a synchronous service and that service is performing complex work that takes a considerable amount of time, the BPEL process service engine transaction can time out. Even though the synchronous service is performing correctly, the BPEL process service engine rolls back once the business process gets a response from a remote service.

13.3.2 Guidelines for Executing Without a Transaction

To execute a business process without a transaction, select notSupported from the Transaction list when creating a BPEL process in the Create BPEL Process dialog.

When set, the following behavior occurs:

All XA distributed transaction benefits are disabled.

When a business process is configured to run in non-transactional mode, the instance execution is not wrapped in an XA transaction, resulting in potential duplicate instances, but no loss of message(s). As there is no overhead of a transaction, the non-transactional mode provides better performance. You can use the non-transactional option where duplicate instances are acceptable.
The business process cannot invoke any partner that expects to participate in a transaction (that is, the partner has the TransactionAttribute set to MANDATORY).
The invoke from the business process is fire and forget (that is, once the invoke is finished, it is delivered to the partner. Even if the invoker's transaction rolls back afterwards, the invoke message is not rolled back).

Even with bpel.config.transaction set to notSupported, the dehydration point starts a transaction to save the internal BPEL process engine state into the back end. This means the dehydration concept still applies for the business process. This feature only guarantees that business process activities such as an assign, an invoke, and others are executed without a transaction.

This property configures the transaction behavior of a BPEL instance in the case of initiating calls. Table 13-5 describes the behavior of the BPEL instance based on the bpel.config.transaction property setting.

Table 13-5 BPEL Process Instance Behavior Based on transaction Property Settings

Transaction Type	transaction = requiresNew	transaction = required	transaction = notSupported
Request/response (initiating)	A new transaction is created for the execution. The existing transaction (if there is one) is suspended.	The process joins a caller's transaction (if there is one) or creates a new transaction (if there is not a transaction).	Business process activities are executed without a transaction. The transaction is only used to save internal service engine/instance state and audit details. Any `bpelx:rollback` fault is not propagated back to the client because the current instance does not participate in the client's transaction.
One-way (initiating, `bpel.config.oneWayDeliveryPolicy=sync`)	A new transaction is created for the execution and the existing transaction (if there is one) is suspended.	The invoke message is processed using the same thread in the same transaction.	Business process activities are executed without a transaction. A transaction is only used to save internal service engine/instance state and audit details. Any `bpelx:rollback` fault is not propagated back to the client.
One-way asynchronous	Not applicable.	Not applicable.	Business process activities are executed without a transaction. The transaction is only used to save internal service engine/instance state and audit details.

13.3.3 How to Create a Synchronous BPEL Process Without a Transaction

You can create a synchronous BPEL process without a transaction in the Create BPEL Process dialog.

To create a synchronous BPEL process without a transaction:

Create a BPEL process service component in the SOA composite application, as described in How to Add a BPEL Process Service Component.
From the Template list, select Synchronous BPEL Process.
From the Transaction list, select notSupported. Figure 13-1 provides details.

Figure 13-1 Create BPEL Process Dialog

Description of "Figure 13-1 Create BPEL Process Dialog"
Click OK.

13.3.4 How to Create an Asynchronous BPEL Process Without a Transaction

You can create an asynchronous BPEL process without a transaction in the Create BPEL Process dialog.

To create an asynchronous BPEL process without a transaction:

Create a BPEL process service component in the SOA composite application, as described in How to Add a BPEL Process Service Component.
From the Template list, select Asynchronous BPEL Process.
From the Delivery list, select sync.

The dialog is refreshed to display the Transaction list.
From the Transaction list, select notSupported. Figure 13-2 provides details.

Figure 13-2 Create BPEL Process Dialog

Description of "Figure 13-2 Create BPEL Process Dialog"
Click OK.

13.4 Using In-Memory SOA to Improve System Performance

You can leverage the Coherence cache associated with WebLogic Server to run your non-transactional business processes in memory. This improves performance and scalability for these business processes, as read and write operations are performed out of the cache. Database performance and management also improves, as the costs associated with continuous disk reads and writes are significantly reduced.

Note:

This SOA Suite feature is part of Oracle Integration Continuous Availability. See the Oracle Fusion Middleware Licensing Information for more details on Oracle SOA Suite for Middleware Options.

In-memory SOA enables short-running processes to live in memory. The process state gets written to the database only when faulted, or at regular, deferred intervals using a write-behind thread. The BPEL state information is dehydrated and rehydrated to/from the Coherence cache.

Enable In-Memory SOA

Enable In-Memory SOA through: SOA Administration > common properties > inMemoryEnvironment.

The WLST Script is /net/slc07yxw/scratch/share/wlst/enableInMemory.py (it assumes server is running at default port 7001. userid: weblogic password:weblogic1. Make a copy and update it for your environment).

connect('weblogic', 'weblogic1') custom() cd('oracle.as.soainfra.config/oracle.as.soainfra.config:name=soa-infra,type=SoaInfraConfig,Application=soa-infra') 
set('InMemoryEnvironment', true) 
exit()

13.4.1 Persistence Settings for In-Memory Flow Instances

The persistence settings for the components comprising a business flow determine when the flow, state, and audit data is persisted to the cache, or the database. This also impacts the flow instance data that appears in Enterprise Manager Fusion Middleware Control.

Table 13-6 lists the various persistence settings and their impact on flow, state, audit, and sensor data.

Table 13-6 Persistence Settings for In-Memory Flow Instances

Completion Persist Policy Description Businesss Flow Instances in Enterprise Manager

Immediate The flow trace, BPEL audit trace, and flow instance state data is always persisted to the database. The behavior is the same as if in-memory SOA is not enabled.

Deferred

Completion Persist Policy	Description	Businesss Flow Instances in Enterprise Manager
Immediate	The flow trace, BPEL audit trace, and flow instance state data is always persisted to the database.	The behavior is the same as if in-memory SOA is not enabled.
Deferred	All flow, audit, and state data is initially persisted to the Coherence cache. A separate write-behind thread performs a deferred write of the cache to the database. The write-behind thread wakes up at periodic intervals, the default being 5 minutes. The number of database round-trips is reduced, and only coalesced data is written to the database every time the write-behind thread wakes up.	You should see all flow instances in Enterprise Manager Fusion Middleware Control. However, as the write-behind thread writes to the database at deferred intervals, the flow data updates happen at intervals determined by the write-behind thread. Enterprise Manager reads its data from the database.
Faulted	The flow trace, BPEL audit trace, and flow instance state data is not persisted for successful executions. If the flow encounters a fault, then all data is persisted to the database. Once the flow has been recovered, all flow data is purged. If a component reaches dehydration point, then the state data is persisted to the Coherence cache. For long running flows that span write delay intervals, the write-behind thread does temporarily persist the state of running instances to the database. These are purged after the instances complete execution.	For flows that use the `faulted` completion persist policy, you should not see flow instances in Enterprise Manager Fusion Middleware Control, except for faulted flow instances. Note that long-running flow instances might transiently show up in Enterprise Manager, as and when they are persisted to the database by the write-behind thread. However, this data is purged after the flow instance completes.

All flow, audit, and state data is initially persisted to the Coherence cache. A separate write-behind thread performs a deferred write of the cache to the database. The write-behind thread wakes up at periodic intervals, the default being 5 minutes.

The number of database round-trips is reduced, and only coalesced data is written to the database every time the write-behind thread wakes up.

You should see all flow instances in Enterprise Manager Fusion Middleware Control.

However, as the write-behind thread writes to the database at deferred intervals, the flow data updates happen at intervals determined by the write-behind thread. Enterprise Manager reads its data from the database.

Faulted

The flow trace, BPEL audit trace, and flow instance state data is not persisted for successful executions. If the flow encounters a fault, then all data is persisted to the database. Once the flow has been recovered, all flow data is purged.

If a component reaches dehydration point, then the state data is persisted to the Coherence cache.

For long running flows that span write delay intervals, the write-behind thread does temporarily persist the state of running instances to the database. These are purged after the instances complete execution.

For flows that use the faulted completion persist policy, you should not see flow instances in Enterprise Manager Fusion Middleware Control, except for faulted flow instances.

Note that long-running flow instances might transiently show up in Enterprise Manager, as and when they are persisted to the database by the write-behind thread. However, this data is purged after the flow instance completes.

The string values immediate, deferred, and faulted are case-insensitive.

As business flows can span composites and components, persistence for a flow comprising components with different persistence settings is determined by the components that persist. So, even if one component is configured to persist to the database, then all components in the flow will persist to the database.

For example, if you have a BPEL component with persistence set to deferred and another BPEL component in the same flow has persistence set to immediate, then the immediate setting overrides the deferred setting, and all flow instance state and flow audit trace data is persisted immediately to the database. Similarly, if you have all components set to faulted, but even one component is set to deferred, then the persistence setting defaults to deferred and flow state and audit data is persisted.

Note:

The component state and component audit trace is persisted based on the persistence policy applied to the component. The flow instance state and flow audit trace is determined by the override rule. So, immediate overrides deferred overrides faulted.
Sensor data is persisted per the flow data. If flow is persisted to the database, then sensor data is also persisted to the database.

Write Delay for In-Memory Flows

The default interval used by the write-delay thread is 5 minutes. This means that the data is copied from the cache to the database every 5 minutes.

If you have a strong case to modify this, say, if most of your BPEL processes complete in 6 minutes, as opposed to 5 minutes, and you wish to tweak the write-delay in order to reduce your database writes, you can set the following server start argument for your SOA server:

-Dsoa.cache.writebehindDelay=6m

The WebLogic Server Administration Console can be used to set server start arguments.

13.4.2 Steps to Enable In-Memory SOA

To enable In-Memory SOA, you need to set the in-memory SOA flag in Enterprise Manager. In addition, you need to design your business processes to be non-transactional, and to use the correct completion persist policy (faulted or deferred).

The following steps are required.

13.4.2.1 Enabling the In-Memory SOA Flag

If you have one or more business flows designed to run in-memory, you need to set the InMemoryEnvironment flag in Enterprise Manager Fusion Middleware Control. After you set the InMemoryEnvironment flag to true (default is false), SOA execution is performed in-memory for components, composites, and flows that have been designed to use this feature.

Use the following steps to set the SOA in-memory environment in Enterprise Manager Fusion Middleware Control.

From the SOA Infrastructure menu, select SOA Administration > Common Properties.
Alternatively, you can also select SOA Infrastructure Common Properties from the SOA Composite menu on a composite page.

The SOA Infrastructure Common Properties page appears.
Click the More SOA Infra Advanced Configuration Properties... link near the bottom of the page.
The System MBean Browser page appears. The attributes for the soa-infra MBean, under Application Defined MBeans, are displayed in alphabetical order.
Scroll down to the InMemoryEnvironment attribute. Set the Value field to true.
Click Apply near the top right of the page.

The SOA in-memory environment is now enabled.

13.4.2.2 Designing Your Business Process to Run In-Memory

To configure a business flow to run in-memory, you must design all the constituent BPEL components to be non-transactional. In-memory SOA can only be used for non-transactional business process as coherence cache does not support transnational behavior at this point. Also, you must set the completion persist policy for all of your BPEL processes to deferred or faulted.

Use the following settings, when adding a new BPEL process, in order to enable your BPEL process to run in-memory.

On the General tab of the Create BPEL Process dialog, select notSupported for Transaction.
Select the In Memory SOA tab to specify the completion persist policy.

13.4.2.2.1 Setting an Existing Business Process to Be Non-Transactional

To ensure that your business process can use in-memory SOA, you must set up the process to be non-transactional.

Use the following steps in JDeveloper to set your BPEL process to be non-transactional.

Ensure that the SOA composite, containing the BPEL process, is open in JDeveloper.

Select the BPEL component in the composite view.
The Properties for the selected BPEL component appear in the Properties window. If the Properties window is not visible, select Properties from the JDeveloper Window menu.
If the bpel.config.transaction property appears in the Properties window, select the property and click Edit. Else, click the Add button to add the property.
The Edit Property or Create Property dialog appears.
If you are adding the property, typebpel.config.transaction for the Name.
Type notSupported under Value.
Click OK.

The bpel.config.transaction property appears in the Properties window. Verify that the Value column reads notSupported.

13.4.2.2.2 Setting the Completion Persist Policy for an Existing BPEL Process

To ensure that your business process can use in-memory SOA, you must set the completion persist policy to deferred or faulted. When the BPEL process comes across dehydration points, the state information is cached in memory, and not the database.

Use the following steps in JDeveloper to set the completion persist policy for your BPEL process.

Ensure that the SOA composite, containing the BPEL process, is open in JDeveloper.

Select the BPEL component in the composite view.
The Properties for the selected BPEL component appear in the Properties window. If the Properties window is not visible, select Properties from the JDeveloper Window menu.
Click the Add button to add the bpel.config.completionPersistPolicy property.
The Create Property dialog appears.
Typebpel.config.completionPersistPolicy for the Name.
Type deferred or faulted under Value.
Click OK.

The bpel.config.completionPersistPolicy property appears in the Properties window. Verify that the Value column reads deferred or faulted.