Global Transactions, Retries and Rollbacks and Fault Policies

2-16 Oracle Fusion Middleware Users Guide for Technology Adapters Specifically, the fault policy, running in its own transaction, commits any existing JTA transaction before it starts executing a particular Reference for example, in Oracle BPEL PM it is an Invoke activity. The pre-existing JTA transaction is not suspended and then committed. Exercise care when using non-transactional adapters, including Oracle File Adapter and Oracle FTP Adapter, with transactional adapters, as retries can affect non-transactional data, including creating duplicate messages. Such care can include, for example, modelling business processes so that message duplicates do not occur.

2.12.3 Basic Concepts of Transactions and Adapters

For additional information on topics related to retryability, see Section 2.22.1, Handling Rejected Messages, and following sections. ■ Polling : All Oracle JCA Adapters, as well as legacy adapters, support a pull, or polling, model for connecting to the back-end application for receiving events, that is, periodically querying the EIS endpoint for available messages and data.The exception to this is the Oracle Socket Adapter, which uses a different set of logistics, where the socket adapter can either connect to the EIS endpoint as the other adapters do using a client socket polling, or, alternatively, create a server socket and then wait for incoming requests push. With polling, connection-related issues are recoverable and the inbound adapters keep retrying until the adapters are able to establish connection with the EIS. The adapter endpoints will attempt to recover a lost connection for the duration of the active life of the composite. During this time they also update the log with diagnostics pinpointing the issue with connection ■ Local retry : These are typically transient connectivity errors. where retries can be tried again and data is not compromised by a retry. However, non-successive local retries can change transaction state. Examples of retryable errors include temporary permission errors andor resource constraint errors. If a transaction can be retried, this does not necessarily mean a rollback. ■ Global retry : A transaction that is rolled back to the beginning of the composite, for example, to a BPEL Receive where BPEL is part of the composite, which is at the beginning of the BPEL flow within a composite application. The transaction can be retried as indefinitely, or as many times as jca.count.retry indicates. Prior to the retry, a rollback can occur. An example could be where there is a BPEL fault in a synchronous process, or where there is a partial update to a database with master and child records and a temporary database fault occurs, and the toplink mapping logic decides a retry is acceptable. In other words, a global retry can occur if data is not tainted and it can be considered an explicit retry, where a rollback is needed. ■ Not-retriable : A transaction that will not be retried. With not-retriable conditions, there is no change to existing state. No-retry conditions derive from binding faults. Not-retriable situations typically occur where database integrity is an issue. Hence, not-retriable transactions are rolled back, once rejected; they are typically related to database constraint issues. Errors such as Data already exists for example, Primary Key Errors are not retriable as well as message correlation ID errors. A list of errors that are not retriable is provided later in this chapter. ■ Inbound transaction : A transaction initiated by an inbound adapter. For example, a transaction entering the SOA system from a JMS system. ■ Outbound transaction : A transaction outbound from the SOA system and hence from an adapter. For example, a transaction that is made against a database outside the SOA system. ADAPTER Life-Cycle Management 2-17 ■ JTA transaction : Every step of a process is executed within the context of a JTA transaction. A JTA transaction ensures that one or more operations execute as an atomic unit of work. See the section on XA above. ■ Asynchronous transaction : A composite transaction composed of sub-transactions. However, these sub-transactions are consecutive and serialized, that is, some of the sub-transactions may have been committed while others may be still executing or have not yet executed. Asynchronous transactions are guaranteed to be propagated once and only once. Once an update at the source is committed, the transaction will commit and expect that the update will be propagated to the target appropriately. ■ Synchronous transaction : These are transactions that execute in one thread from one endpoint to another, without intermediate processes, and which are not serialized.

2.12.3.1 Asynchronous Transaction Flow

In the following sections, asynchronous and synchronous transactions are illustrated through a canonical combination set of adapters, JMS and DB, with BPEL technology intermediary. The example could employ other adapters, and other intermediaries, for example, the Mediator. For an asynchronous service entry point, a transactional adapter initiates a global JTA transaction before sending an inbound message to the composite.

2.12.3.1.1 Example using JMS, BPEL, DB Adapter and a Database

The example described below uses a test composite bound to the JMS adapter, which is bound to a composite bound in this example to BPEL which in turn is wired to a DB Adapter. BPEL dispatches messages to the DB adapter. In this example, messages are read from JMS by the polling JMS Adapter and written to the BPEL process, where there the transaction commits. This is JTA1, the first XA transaction. For any BPEL activity errors that, however, could not be retried or which exhausted their retry count, BPEL writes to its recovery table to store information. This information includes BPEL errors. The second transaction, JTA2, begins with the DB Adapter reading from the BPEL dispatch table, obtaining the database insert argument. and writing an update message to the DB Adapter. This transaction, JTA 2, proceeds Outbound from the reference endpoint DB Adapter that is, Outbound from SOA to the Database itself. Retry situations from a duplicate data situation in the Database are retried either back from the DB Adapter to BPEL’s table, or from the database back to the DB Adapter. Global retries for any error handling are returned to the BPEL Receive activity instance, for example, or, more generally, to the point at which the transaction started. Such a retry could occur if there was an error such as a temporary database fault. The default retry count is by default indefinite, or specified in the jca.retry.count property. If any errors are caught as part of the second XA transaction, JTA2, a rollback occurs.

2.12.3.2 Synchronous Transaction Flow

For a synchronous process, the global transaction initiated by the adapter spans both: ■ Message delivery