How to use Singleton Design pattern in a Clustered Environment?

[Anil Kumar Saha]

Suppose there are N numbers of nodes in a Clustered Environment. If we use normal below Singleton Design pattern, it will create one object per node(JVM).

  
public class MySingleton { 
 private static MySingleton _instance; 
 
 private MySingleton() { 
  // construct object . . . 
 } 
 
 // 
 public static synchronized MySingleton getInstance() { 
  if (_instance==null) { 
   _instance = new MySingleton(); 
  } 
  return _instance; 
 } 
  // Remainder of class definition . . . 
}
 

But is it possible to implement some design pattern which will ensure that ONLY one object is created in the whole clustered environment?

[Naveen K Garg]

Hi Anil,

I found following article on Server Side website.

J2EE Singleton

Hope this will help.

Regards
Naveen

[Stan James]

That TSS article was interesting, and the many responses even more interesting. They talked about several ways to get the singleton state out of every JVM in the cluster and into a single point. Which should probably be capitalized as potential Single Point Of Failure.

You shouldn't feel restricted to Java for solutions; anything outside the JVM that provides shared state, concurrency controls, persistance over time, failover, etc. would work. Hmmm, sounds kinda like a database.

And, as always with Singleton, back up and ask yourself why Singleton is necessary. For your clustered situation ... Would a database do the trick? A distributed cache? What kind of latency can you tolerate in making a state change in one machine show up in another? How bad is it if there are two copies of the data?

[Anil Kumar Saha]

Thanks Grag for the link.

James,
I went through the discussion thread and unfortunately not able to get the answer.
So, can we conclude that we should not use Singleton design pattern for the application which will be running in clustered environment?

[Peer Reynders]

Originally posted by Anil Kumar Saha:
But is it possible to implement some design pattern which will ensure that ONLY one object is created in the whole clustered environment?

So, can we conclude that we should not use Singleton design pattern for the application which will be running in clustered environment?

Could you elaborate why it is important that only one object can exist in the entire clustered environment? What if a second JVM wants to simply query it rather than modify it - would a second read-only version be acceptable?

If you can explain the motivation for only wanting one single object someone may be able to help.

Use your singletons wisely

[Anil Kumar Saha]

Could you elaborate why it is important that only one object can exist in the entire clustered environment?

Take for example a Database Connection object, which is extremely critical and expensive in database driven application. Is it not possible to create only Database Connection object per Cluster?

What if a second JVM wants to simply query it rather than modify it - would a second read-only version be acceptable?

I did not get your question. Suppose there are four JVMs in a Clustered environment. If we create a Connection object in JVM1,then copying the object to JVM4 will guarantee that only one object is created?

[Frank Carver]

Take for example a Database Connection object, which is extremely critical and expensive in database driven application. Is it not possible to create only Database Connection object per Cluster?

That sounds like very strange logic.

The reason typical database connections are relatively expensive is because they involve a network connection with the database, some setup when that connection is established, and teardown when it is released. Thus it makes sense to share a database connection (or re-use connections from a pool) within one JVM. Fetching a reference to an already loaded object with an open connection is a much cheaper process.

In a clustered environment, however, communication between nodes is also a network connection, which is also much slower than direct in-memory access. Also underneath each database connection object is a handle to a network connection, which includes details of the source and destination machines. Moving that connection object to another machine would not make much sense.

For the reasons above, and I'm guessing many more, I'm finding it really hard to imagine a situation in which trying to create and pass around a single database connection object between machines would ever be a better solution than a local database connection pool in each JVM.

Passing around pre-created business objects, on the other hand, can often be useful. If the object contains data which would be very expensive to recreate (requiring human interaction, for example) then the overhead of passing it from one JVM to another is minor. Even in this case, though, the idea of trying to use the Singleton pattern sounds crazy.

Can anyone else come up with a realistic use for Singleton in a clustered environment?