Oracle SOA: DB Adapter Singleton behaviour in High Availabilit...

Oracle SOA: DB Adapter Singleton behaviour in High Availabilit...: There was a problem which one can face in high availability environment (clustered) . We had one Integration between Oracle Ebiz a...

DB Adapter Singleton behaviour in High Availability Environment

There was a problem which one can face in high availability environment (clustered) . 

We had one Integration between Oracle Ebiz and third party system in which we get data from Oracle Ebiz and send them to third party application. This integration was running fine till the time our server environment upgraded for high availability means clustered ones...

We had two clustered which were configured to be synchronous to idealised HA situation. But this causes one design issue in that Integration. 

The issue starts coming in our DB Adapter that now the DB Adapter starting polling Staging table(OEBS)  in parallel with the initialised interval. Cluster1 and Cluster2 starts initiating DB Adapter instances in parallel and if we increase the clusters form 2 to 3. The same way three instances of pooling components started. Which leads to a situation in which if we increase the clusters in future from 2 to 50 then in parallel 50 instances of pooling component will be created in parallel and will hit the third party application in parallel. This could be a problem for a target system if it doesn't supports parallel processing.

The solution to this problem was that we need a concept of singleton pattern in our pooling component / DB Adapter.

There's a property of Inbound endpoint lifecycle support within Adapters called Singleton.
To enable this feature for high availability environment for a given inbound adapter endpoint, one 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 shows.

Singleton Property in composite.xml

    <binding.jca config="bindin_file.jca">
        <property name="singleton">true</property>
    </binding.jca> 

This was our finding to the problem we faced in clustered environment.

I hope this helps others as well.