Clustered Singleton

[H Gokulam]

How can we implement clustered singleton ? I am using a singleton class in Tomcat. Now we are planning to have clustered servers for the same application. How can I achieve the same functionality in clusetered environment ?

Hari

[Stan James]

Interesting problem. At a high level you'll have to find a home for the singleton and provide a way for all servers in the cluster to work with it. Maybe it's a Java class with pub-sub or remote access. Maybe it's not Java at all, but an entry in a database, LDAP or some other shared resource. We'd have to know the purpose and requirements to work up an architecture.

We have a distributed system that has an in-memory list of all users currently logged on. There is a pub-sub mechanism to broadcast any changes on one server to all the others. Somewhere deep in vendor code that we don't have source for they handle a server stops and restart ... how does it get back in sync?

A previous version of this vendor package (in Forte 4GL not Java) had a singleton obect with distributed access, and a hot-backup that was kept in sync somehow. If the primary failed, the backup took over. This was complex enough that I probably wouldn't try it again.

[Reid M. Pinchback]

Depending on the performance issues, you can make a clustered singleton by keeping its state persisted via entity beans. Getting the raw singleton behaviour is simple via row locking, but getting good performance could take some experimentation with the vendor-specific options for a read-mostly idiom. However, none of that is an option in raw Tomcat, only if you use Tomcat as the front-end for an EJB container. From what I see in the Tomcat clustering docs, it doesn't sound like something you'd want to try to emulate in a purely Tomcat solution.
[ February 10, 2006: Message edited by: Reid M. Pinchback ]

[Frank Carver]

I'd guess it depends a lot what your Singleton actually needs to do.

If it's something simple such as issuing a guaranteed unique id when asked, then keeping a count in a database and having a "singleton" in each JVM which queries a shared database would probably do it.

If it's more complex, then maybe the "half object plus protocol" pattern might be a better choice - the "singleton" in each JVM is just a shell around some code that makes a network connection to some master object in another JVM which actually does the work, serializing objects across the pipe (in some form) where necessary.

The most important thing with all this, though is to work as hard as you can to separate the code/data which must be in only one place, from the code/data which happens to be in only one place at the moment.

Can you tell us any more about what your Singleton is used for?

[Vishal Angrish]

Why not to configure the Singleton Component on just one server among cluster if clustering is used mainly for Load Balancing, But consedering aspect of fail over support, you need to deploy on all nodes and probably need to wrap this component with another class, which will keep the central Db updated with the Node ID, from which, instance is already been exposed, and then get the reference from the same server(Considering this component will have JNDI binding), and if that server node is enable to process the request create a new instane of singleton class and update the DB with current Node ID, so as for next retreival other nodes can get the reference from this node.

[Vishal Angrish]

I think contractly and conceptually, having a singleton class in cluster(mutiple jvms) may jusy single instance in group, but Implementaion wise it wont be wrong, to keep single instance/jvm and manipulate the shared resources either using DB/ldap/file system.

[H Gokulam]

Thanks for the replies.

We are using it mainly for keeping track of the transactions (which are pending for authorisation), online users etc.

Currently we have implemented a solution using database. But we need to find out a better way.

Thanks

[Stan James]

What kind of problems make you want to move off the database? The database sounds like a solution I'd probably like. They're just awfully good at that shared access stuff.

[H Gokulam]

Hello Stan,

Most of our pages used to take the data stored in the Singleton for allocation , monitoring etc. The performance is an issue in case of the database solution. We are not in a position to change all these access to Singleton data, even though some of them can be removed.

We are trying to keep the changes only in this Singleton class. One solution could be to keep the data in Singleton class as well as in the database. But then there should be a mechanism to update the Singleton classes in different JVMs, whenever a change occurs in the database. May be a thread, which keeps checking the DB for any changes..........

[Stan James]

Gotcha.

I think with the rapid updates going on you'll want a single shared resource rather than a replicated one. Assuring synchronization across replicants is tough.

But you probably still need one replicant or persistence for failover. A single shared resource is a single point of failure. A persistent resource like a database might be safe. In my world if the database is down nothing interesting is happening, so I'd never have db failure and a working app trying to update the resource.

Take some time and code a few of these up: database (you have), remote EJB on one server in the cluster, JNDI, flat file (yuck) and whatever else you think of. See how the timings compare UNDER LOAD. Compare the complexity and risk for concurrency, failover, etc. Something that works for you will emerge, I'm sure.

[H Gokulam]

Hi Stan,

Thank you very much for your suggestions. We are working on it.

Hari

[Babji Reddy]

Can JMS be a solution to this problem. To write the data, post it to a Queue, and have a MDB listen to it and update it to the database.
On the reading side, its doesn't affect performance to have multiple singleton 'caches' per JVM in cluster that refresh the data from the DB...

[H Gokulam]

We also thought of JMS as a solution. But we believe database is the right solution, but with little bit of fine tuning.

Regards,
Hari
[ February 19, 2006: Message edited by: Hari G ]

[Stan James]

A random neuron just fired in my brain ... President's Day off and all ... If you have a regular "operational database" doing lots of inserts and queries and running your real business, you might want to separate this shared resource thingy into its own database instance. We did that with one specialized db so we can tune it independently of the main db, and I expect to add another instance soon for read-only archived data from another system.

[H Gokulam]

Stan,

Very good idea. This something we never thought of. Thanks a lot.