How to Disable Assertions What Happens When You Create Assertion Conditions

11-54 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite 12 Transaction and Fault Propagation Semantics in BPEL Processes 12-1 12 Transaction and Fault Propagation Semantics in BPEL Processes This chapter describes transaction and fault propagation semantics in Oracle BPEL Process Manager. This chapter includes the following sections: ■ Section 12.1, Introduction to Transaction Semantics ■ Section 12.2, Introduction to Execution of One-way Invocations

12.1 Introduction to Transaction Semantics

Transaction semantics in release 11g 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

12.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 release 11g, 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. 12-2 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite Example 12–1 provides details. Example 12–1 Setting a New Transaction component name=InternalWarehouseService implementation.bpel src=InternalWarehouseService.bpel property name=bpel.config.transaction many=false type=xs:stringrequired | requiresNewproperty component There are two possible values: required and requiresNew. Table 12–1 describes these values and summarizes the behavior of the BPEL instance based on the settings. For additional information about setting the bpel.config.transaction property, see Section C.1.1, How to Define Deployment Descriptor Properties. The following sections describe the transaction and fault behavior of setting bpel.config.transaction to either required or requiresNew. 12.1.1.1 BPELCaller Calls BPELCallee That Has bpel.config.transaction Set to requiresNew In Table 12–2 , the BPELCaller process calls the BPELCallee process. The BPELCallee process has the property bpel.config.transaction set to requiresNew. Table 12–2 describes fault propagation and transaction behavior when bpel.config.transaction is set to this value. Table 12–1 bpel.config.transaction Property Behavior For... With bpel.config.transaction Set to required... With bpel.config.transaction Set to requiresNew... Requestresponse 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.oneWayDel iveryPolicy 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. Table 12–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. Transaction and Fault Propagation Semantics in BPEL Processes 12-3

12.1.1.2 BPELCaller Calls BPELCallee That Has bpel.config.transaction Set to required

In Table 12–3 , the BPELCaller process calls the BPELCallee process. The BPELCallee process has the property bpel.config.transaction set to required. Table 12–3 describes fault propagation and transaction behavior when bpel.config.transaction is set to this value. 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 BPELMasters 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. 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. Table 12–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. Table 12–2 Cont. BPELCaller Calls BPELCallee That Has bpel.config.transaction Set to requiresNew If The BPELCallee... Then The BPELCallee Transaction... And The BPELCaller...