Adapter Support of Local Transactions

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.