Migrating Repositories from Different Environments

2-14 Oracle Fusion Middleware Users Guide for Technology Adapters The weblogic-ra.xml identifies the end point as a development EIS or testing EIS or production EIS. For example, consider that when running through the Database Adapter Service Wizard, you specify eisDBcustStore as the JNDI name for the createCustomer service. After modeling the composite by using this adapter service, you should deploy it to the development, test, or production environments without making any changes. But before you do this, ensure that you have a corresponding JNDI entry for eisDBcustStore in each of your various environments pointing to the right EIS instance. To summarize: ■ All JCA files reference the JNDI name as defined in the weblogic-ra.xml file ■ You must update the weblogic-ra.xml file to have the same JNDI name in all your environments in which it is deployed. ■ Use the weblogic-ra.xml deployment descriptor to specify values for deployment time properties, such as retry interval and retry count. This file also identifies the end point’s environment. ■ Before deployment, ensure you have a corresponding JNDI entry for the correct environment.

2.12 How Oracle JCA Adapters Ensure No Message Loss

This section describes how adapters ensure that messages are not lost. Transactional adapters allow the Enterprise Information System EIS to participate in one-phase or two-phase commits local transactions or globaldistributed transactions. Non-transactional adapters implement their own schemes to ensure delivery, without the use of transactional semantics. This section describes: ■ Section 2.12.2, Local Transactions and Global XA Transactions ■ Section 2.12.3, Basic Concepts of Transactions and Adapters ■ Section 2.12.5, Outbound Transactions For more information, see: ■ Section 2.13, Composite Availability and Inbound Adapters ■ Section 3.1.1, Oracle WebLogic Server Overview ■ Section 5.9.1.2 Oracle JCA Adapters Reliability and Transactional Behavior in the Oracle Fusion Middleware High Availability Guide.

2.12.1 XA Transaction Support

The goal of XA is to allow multiple resources such as databases, application servers, message queues, transactional caches to be accessed within the same transaction. XA uses a two-phase commit to ensure that all resources either commit or rollback any particular transaction consistently. The XA specification describes what a resource manager must do to support transactional access. Resource managers that follow this specification are said to be XA-compliant. ADAPTER Life-Cycle Management 2-15 XA transactions are part of the scenario you use when you want to work with multiple resources: for example, or two or more databases, or a database and a JMS connection, or all of these plus the adapter, all in a single transaction. Transactional adapters enable XA transaction support, which, along with the inherent data processing, ensures that each modification has a clearly defined outcome, resulting in either success or failure, thus preventing potential corruption of data, It ensures execution independently from other changes, and, once completed, leaves underlying data in the same state until another transaction takes place. XA is a two-phase commit protocol, more robust than a one-phase commit or emulated protocol. With a one-phase, or emulated, protocol, you might still see message loss or other rollbackcommit inconsistency.

2.12.2 Local Transactions and Global XA Transactions

An XA transaction is a transaction started by an application servers transaction manager. All XA resources must participate in any active global transaction, and only commit or rollback when provided a signal by the transaction manager. If a failure to commit occurs after the signal is received, a recovery mechanism must also exist to ensure the commit eventually happens. Note that a non-participating local resource can start and end a local transaction irrespective of an active global transaction. The commit can be done immediately and is not in response to a signal from the transaction manager. If the commit fails, the transaction is rolled back instead, with an exception thrown. No special recovery is required for that transaction because there is no other resource with which to synchronize its commit.

2.12.2.1 Adapter Support of Local Transactions

Adapters define the type of transaction support by specifying the transaction-support element in the ra.xml deployment descriptor file.

2.12.2.2 Adapter Support of Global Transactions

Adapters support global transactions in the JCA 1.5 XA contracts that leverage the underlying application server transaction manager. The types of adapters that leverage the underlying application transaction manager includes Oracle Adapter for Oracle Applications, Database, Advanced Queuing, JMS and MQSeries Adapters. Non-transactional adapters, which do not leverage the underlying transaction manager, include Oracle File Adapter and Oracle FTP Adapter.

2.12.2.2.1 Global Transactions, Retries and Rollbacks and Fault Policies

A global transaction can be marked rolled back by any parties that participate in the global transaction. Once a party marks the global transaction for rollback, other parties will not be able to revoke the rollback, The fault type indicates if the errors are retryable. If retryable, the retries will be governed by the JCA retry properties, which will be discussed in length in the error handling section. If the error is deemed unretryable, the handling of such an error will be governed by the fault policy, in which case the fault policy gets executed. This is the same for both inbound and outbound adapters. Actions performed by a fault policy will be in its local transaction and not in the global transaction.