Example using JMS, BPEL, DB Adapter and a Database

2-18 Oracle Fusion Middleware Users Guide for Technology Adapters ■ Composite execution As with asynchronous transaction flow, the default retry count is indefinite, but can be specified through jca.count.retry. Synchronous transaction flow is similar to the asynchronous flow, with these differences: ■ Flow consists of request-response messages between the JMS Adapter and intermediary processing, for example, BPEL processing, and between, using the same example, BPEL and the Database Adapter, where messages requesting, for example, an insert are written. With a synchronous transaction, a retryable error is not caught by BPEL the example intermediary within the composite; the transaction returns all the way back to the JMS adapter for possible global retry. ■ The synchronous transaction is just one JTA transaction, rather than two. ■ The Adapter rejection table keeps a record of adapter rejections. Within the context of a synchronous transaction, local BPEL error handling is bypassed, and with a synchronous transaction, the private BPEL table does not contain relevant Adapter rejection data. The data is instead kept in the Adapter rejection table. ■ Local retries that exhaust the retry count are stored in the BPEL recovery table. Using a similar example as that used in the synchronous example, and keeping in mind that an example synchronous message flow, parallel to the one used in the asynchronous example, consists of only one JTA transaction, JTA 1, throughout the transaction, processing is straightforward. The transaction starts with a polled message Inbound to the service endpoint, a JMS read message that then writes to the BPEL process. Unlike the situation with the asynchronous transaction, with a synchronous transaction, the JTA transaction does not commit at this point. Instead, the same JTA transaction proceeds Outbound from the reference endpoint DB Adapter to the Database itself. The message is then read from BPEL, and the DB Adapter is invoked with the insert argument from BPEL. At this point the JTA transaction commits. As with asynchronous transactions, retries can be global and subject to a count indicated in the jca.retry.count property. In this example, faults which are locally retryable are tried either from the database back to the BPEL process or from the Database back to the DB Adapter.

2.12.4 Inbound Transactions

Inbound the adapter runs in an autonomous work thread; the adapter is in charge of connection recovery, and uses its own retry properties for example, adapter.jms.retry.interval. A transactional adapter initiates a global JTA transaction before sending an inbound message to a composite. For transactional adapters, retries can either be local retries for example, a BPEL remote fault, global, or no retry similar to a binding fault. Global retries are returned to the location where the transaction started. The default retry count is again, by default, indefinite, but are retriable only as the jca.retry.count specifies. When control returns to the adapter, the adapter commits the JTA transaction, and executes the following set of actions as an atomic unit of work. The adapter: