Oracle Database Adapter high availability/Scalability

Oracle Database Adapter can be configured for high availability in two models with in cluster environment

1. Active-Active
2. Active-Passive 

Active-Active setup.
In an active-active setup, distributed polling techniques can be used for inbound database adapters to ensure that the same data is not retrieved more than once.

One of the best practices for multiple Oracle database Adapter process instances deployed to multiple cluster nodes is to use the adapter configuration wizard to set the Distributed Polling check box in the Adapter

With an Oracle DB, this automatically creates SQL select appended with SELECT FOR UPDATE SKIP LOCKED. Concurrent poller threads from each node trying to select and lock the available rows will follow below orchestration,
If current row is locked, the next unlocked row is locked and fetched instead. If many threads all execute the same polling query at the same time, they should all relatively quickly obtain a disjoint subset of unprocessed rows.

With a non-Oracle database the SELECT FOR UPDATE safely ensures that the same row cannot be processed multiple times, however you should consider taking additional measurements like using a partition field or singleton property as a best practice

Active-Passive :
We use Singleton property in composite.xml for active-passive setup. This allows multi threaded inbound Oracle Database Adapter instance to follow a fan out pattern and invoke multiple composite instances across a cluster. The Oracle DB Adapter supports the high availability feature when there is a database failure,restart or crash . The DB adapter picks up again without any message loss.

This is essentially multi-threading on a single node with fan-out to multiple composite instances running on multiple nodes

Singleton (Active/Passive) is applicable only for inbound endpoint adapters
Set this property in the composite.xml within the element and set it to a value of true as shown in example.
This  property can be set for any JCA adapter

Example:
<service name="databasepoll" ui:wsdlLocation="databasepoll.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/...#wsdl.interface(Subscr_ptt)"/>
<binding.jca config="databasepoll_db.jca">
<property name="singleton">true</property>

</binding.jca>
</service>

Note:This property is not applicable to outbound adapters

How singleton works: If there are multiple activations of the same adapter endpoint for same composite service in an Oracle WebLogic cluster is identified, then only one activation is allowed to start the reading or publishing of messages.The JCA binding component instances choose one among the activations randomly as the primary activation responsibility and all other as Standby

If a primary activation at some point of time becomes unresponsive,unavailable or crashes then
remaining JCA binding component members of the Oracle WLS cluster immediately detect the deactivation, and reassign the primary activation responsibility to one of available endpoints

For scalability, think of setting below properties
Set MaxTransactionSize and increase concurrency by setting the adapter _db.JCA property NumberOfThreads.