1. Developing SOA Applications with Oracle SOA Suite
  2. Using the BPEL Process Service Component
  3. Transaction and Fault Propagation Semantics in BPEL Processes
  4. Introduction to Transaction Semantics
  5. Oracle BPEL Process Manager Transaction Semantics
  6. BPELCaller Process Calls a BPELCallee Process That Has bpel.config.transaction Set to required

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