Singleton

Duplicate instances when using DB adapter in high availability environment.


Many a times I have noticed that when you use DB Adapters (SOA Suite 11g) for integrating with applications like the E Business Suite in a clustered high availability environment, at times there will be multiple instances for the same request.

The number of instances each entry in the DB would generate would directly correlate to the number of nodes on a cluster.

Such that if there are 3 nodes on the soa cluster then the polling composite deployed on each of the managed servers would be attempting to process this file and you would end up with extra instances of the composite which would result in errors or processing the item multiple times depending on the business process.

There are 2 different solutions for this problem on the blogs and you can chose anyone depending on which one suits your particular scenario.

However I prefer the quick an easy one to use the singleton property of the JCA DB adapter .

Ideally you would want to do this from the source in the composite.xml

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>

More details about this are available @

http://docs.oracle.com/cd/E23943_01/integration.1111/e10231/life_cycle.htm#BABDAFBH

Runtime Fix

However on an already deployed composite you can go composite dashboard and open the properties tab for the db adapter component from the EM console and add a new property
you will see ‘singleton’ in that list and we can set it to ‘true’

Click Apply and Save.

This should result in the following row in your composite.xml which you can check from the xml definition in the composite dashboard.

<property  name="singleton"  type="xs:boolean"  many="false"  source="PollNYSolutionsJobsEBizReqABCS_ptt:receive[hdr]">true</property>

which is the equivalent of the change in the source code, Obviously you will lose this change if a subsequent deployment happens so make sure this is replicated to the source code as well.

The same can be achieved in OSB using by editing the Configuration Details of the proxy service and set ‘Topic Message Distribution’ to ‘One Copy Per Application’.

Refs:
http://javaoraclesoa.blogspot.co.uk/2012/04/polling-with-dbadapter-in-clustered.html
http://ayshaabbas.blogspot.co.uk/2012/11/db-adapter-singleton-behaviour-in-high.html

		
Advertisements

Singleton Design Pattern


If we are talking about Design Patterns, One of the most common pattern that crosses your mind is Singleton Design Pattern.

The underlying definition of the same is “Ensure a class only has one instance, and provide a global point of access to it.”

Even though it is simple and most of you might already know this, but at times it gets confusing, And as there is No right or wrong approach to it, I will discuss a few of the most common approaches in this post.

Approach 1
In this approach we create a static final variable which will hold our unique instance.
Next we make sure that no can access the constructor to create a new instance, So we make the constructor private.
Now in order to allow access to this instance we create a public Static method which returns you the uniquely created instance of our class.

public class Nitin {

private static final Nitin singletonInstance = new Nitin(); // my unique instance

// Private constructor prevents instantiation from other classes
private Nitin() {
}

public static Nitin getInstance() {

return singletonInstance;
// returns you the same instance we created
}
}
}

Approach 2 – using a static block of code to instantiate.


private static Nitin singletonInstance = null; // instance has not been
// created yet.

// Private constructor prevents instantiation from other classes
private Nitin() {
}

static {
singletonInstance = new Nitin();
// ensures that the instance is only created when it is first needed.
}

}

Approach 3 – we can check in the getInstance method if the instance was created. It ensures that your instance is only created when it is needed.

public class Nitin {

private static Nitin singletonInstance = null; // instance not created yet

// Private constructor prevents instantiation from other classes
private Nitin() {
}

public static Nitin getInstance() {

if (singletonInstance == null) {
singletonInstance = new Nitin(); // my unique instance
}
return singletonInstance;
}
}

Well as we say that there is always a way out 🙂 If you want to break something then no one can stop you…

There is a crack to singleton implementation which I came across recently. Even though you should not try that on someone’s code but there is no harm if you just did for fun,

class CrackingSingleton {

public static void main(String[] args) throws IllegalArgumentException,
InstantiationException, IllegalAccessException,
InvocationTargetException, ClassNotFoundException {

Class clazz = Class.forName("Nitin"); // loads the class

Constructor[] cons = clazz.getDeclaredConstructors();
// gets the constructors

cons[0].setAccessible(true); // changes the access rights

Nitin noMoreSingleton = (Nitin) cons[0].newInstance();

// we have our new instance

}
}

[ad]