Singleton in Cluster environment

Question

What is the best strategy to refactor a Singleton object to a cluster environment?

We use Singleton to cache some custom information from Database. Its mostly

Answer 1

There are products for having a distributed in memory cache (such as memcache) that can help in this situation.

A better solution, if possible, may be to have the singletons not really be single, but have the application tolerate having separate instances (say that all recognize when they need to be refreshed) but not that they have to be in sync across JVMs, that can turn your cache into a bottleneck.

Answer 2

The simplest approaches are:

1. Add an expiry timer to your singleton cache so that every so often the cache gets purged and subsquent calls fetch the updated data from source (e.g. a database)

2. Implement a notification mechanism for the cache using something like a JMS topic/tibRV. Get each cache instance to subscribe and react to any change messages broadcast on this topic.

Answer 3

Replace your singleton cache with a distributed cache.

One such cache could be JBoss Infinispan but I'm sure that other distributed cache and grid technologies exist, including commercial ones which are probably more mature at this point.

For singleton objects in general, I'm not sure. I think I'd try to not have singletons in the first place.

Answer 4

There are several ways to handle this, depending on 1) how out of data the data is, and 2) does every instance need to have the same values all of the time.

If you just need data that is reasonably up to data, but every JVM doesn't need to have matching data, you can just have every jvm refresh its data on the same schedule (e.g., every 30 seconds).

If the refresh needs to happen at about the same time, you can have one jvm send out a message to the rest of them saying "its time to refresh now"

If every jvm always needs the same information, you need to do a sync, where the master says "refresh now", all of the caches block any new queries, refresh, and tell the master that they are done. When the master gets an answer back from every member of the cluster, it sends another message that says to proceed.

Answer 5

If possible, use your app server's support for this, if possible (some have it, some don't). For example, we use JBoss's support for an "HA Singleton" which is a service that only runs on the cluster master node. It's not perfect (you have to handle the case where occasionally it brain farts), but it's good enough.

Failing that, you may be able to engineer something using JGroups, which provides with cluster node auto-discovery and negotiation, but it's non-trivial.

As a last resort, you can use database locking to manage cluster singletons, but that's seriously fragile. Not recommended.

As an alternative to a cluster singleton, you could use a distributed cache instead. I recommend JBossCache (which doesn't need JBoss app server to run) or EhCache (which now provides a distribution mechanism). You'll have to reengineer your cache to work in a distributed way (it won't magically just work), but it's probably going to be a better solution than a cluster singleton.

Answer 6

I'm with Mr. Vest Hansen on this one, move as far away from singletons as you possibly can. After being plaguged with the nightmare that is SAAJ and JAXP and getting compatible versions working on JBoss, I'm done with singletons and factories. A SOAP message shouldn't need a factory to instantiate it.

Okay, rant over, what about memcache or something similar? What sort of affinity do you need for your cache? Is it bad if it's EVER out of date, or is there some flexibility in how out of date the data can get?