Inbound Transactions How Oracle JCA Adapters Ensure No Message Loss

ADAPTER Life-Cycle Management 2-19 ■ Commits the removal of the message from the inbound adapter endpoint for example, table and queue. ■ Commits the execution of the composite instance. If anything fails during this set of commit actions, that is, in removing the message and executing the composite instance, both actions are rolled back.

2.12.5 Outbound Transactions

All outbound transaction composite activities, including Oracle JCA adapter invocations, will be part of a global transaction, and if an error occurs the default behavior is that all activities are either committed or rolled back. For example, a BPEL process can insert data into several tables on different databases through different Invoke activities invoking the Database adapter. When the BPEL instance is about to finish, the JTA transaction is committed. Only at that point will the database insert operations be committed. However, if errors occur during the BPEL instance execution, all activities and thus database operations are rolled back to the last BPEL dehydration point the last time the BPEL instance was stored to a database. Whether an outbound transaction is retryable depends on the nature and scope of a specific interaction. Specifically: ■ Interactions that involve integrity, for example, database integrity, on the target side of the Outbound transaction, will not be retried. ■ There can be local retries where a locally retriable condition exists, for example, a minor database issue with a single record. ■ If the retry situation is a more complicated database integrity scenario that could possibly be corrected, for example, an issue with updating both a Master Detail and a child record, the transaction might be rolled back to its beginning, back to a BPEL Receive if BPEL were part of the scenario, and the transaction started again. The retry is again subject to jca.retry but also could be subject to any BPEL fault handling retry parameters. ■ Connectivity issues outbound from an adapter are typically always retryable. For an outbound transaction, the adapter throws a retryable exception when it cannot get a connection, and then lets the appropriate JCA binding conduct retries via jca.retry.count. An example for a connectivity retryable error related to an outbound interaction is where a database listener might not have started and, accordingly, that state might be issuing connection errors.

2.13 Composite Availability and Inbound Adapters

Oracle WebLogic Server migration is used on WebLogic platform so that if a managed server or machine fails, it automatically restarts on the same or another machine and inbound adapters to a composite on the failed server will then resume functioning. Meanwhile, inbound adapters in other cluster members continue working servicing messages. For more information, see: 2-20 Oracle Fusion Middleware Users Guide for Technology Adapters ■ Section 2.14, Singleton ActivePassive Inbound Endpoint Lifecycle Support Within Adapters ■ File and FTP adapters: Section 4.2.18, High Availability ■ Database adapter: Section 9.3.7, High Availability ■ MQ adapter: Section 10.3.4, High Availability ■ Section 2.12, How Oracle JCA Adapters Ensure No Message Loss ■ Section 5.9 Oracle JCA Adapters and High Availability Concepts in the Oracle Fusion Middleware High Availability Guide.

2.14 Singleton ActivePassive Inbound Endpoint Lifecycle Support Within Adapters

The JCA Binding Component supports active fail-over of inbound Adapter Services. To enable this fail-over feature for a given inbound adapter endpoint, you must add the singleton JCA service binding property in the composite.xml within the binding.jca element and set it to a value of true as Example 2–1 shows. To disable this feature, set the singleton property to a value of false or remove the property from the binding.jca element. Example 2–1 singleton Property in composite.xml service name=JmsTopicSubscr ui:wsdlLocation=JmsTopicSubscr.wsdl interface.wsdl interface=http:xmlns.oracle.com...wsdl.interfaceSubscr_ ptt binding.jca config=JmsTopicSubscr_file.jca property name=singletontrueproperty binding.jca service

2.14.1 Multiple Activations of the Same Adapter Endpoint

In an Oracle WebLogic cluster, multiple activations of the same for example, JMS adapter inbound endpoint for a specific composite service are detected implicitly and automatically by all instances of the adapter framework active in that cluster. However, only one activation will be allowed to start the reading or publishing of messages. The JCA Binding Component instances choose one among the activations, randomly the activation that will assume the Primary Activation responsibility.

2.14.2 Hot-Standby State

The other activations also called instances in the Oracle WebLogic cluster initiate to a hot stand-by state, without invoking EndpointActivation on the JCA resource adapter. These activations can be reassigned primary activation responsibility. If a primary activation at some point becomes unresponsive, is deactivated manually, or crashes or exits, any one of the remaining JCA Binding Component members of the Oracle WebLogic cluster immediately detect this, and reassign the primary activation responsibility to one of activation agents that is in stand-by state.