Java Answers Forum - Concurrent Singleton usage - Limitations ?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Java Answers Forum
Concurrent Singleton usage - Limitations ?

16 replies on 2 pages. Most recent reply: Jul 4, 2004 10:57 PM by Shashank D. Jha

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Jai

Posts: 5
Nickname: jarulraj
Registered: Apr, 2004

Concurrent Singleton usage - Limitations ?

Posted: Jun 28, 2004 11:33 PM

Reply

Advertisement

I have a scenario where all the communication from an application is handled through a common interface. I have modelled a singleton through which all these happen.

I would like to know whether there are any restrictions in terms of the singleton usage(this is in the app tier). Wherein, if multiple users invoke the getInstance, though synced, is there any limitations in terms of number of users ?

The users range from many hundreds to thousands.

Any pointers are suggestions is welcome.
Thanks in Advance!

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jun 29, 2004 1:18 AM

Reply

Limitation comes because of obvious way of usage. Esp when all want synchronized access to this Singleton object.

It will defiitely lead to overhead each time when some one wants to get hold of its reference, before invoking any operation.

And for large number of client, definitely is a kill for your application.

And unless there is definite need of such an object, avoid it.

regards,
Shashank

Jai

Posts: 5
Nickname: jarulraj
Registered: Apr, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jun 29, 2004 2:20 AM

Reply

Thanks Shashank!

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 1, 2004 1:43 PM

Reply

Maybe I don't understand the problem exactly, but it seems to me that if you have an object which is a singleton there is a reason for it being so. If that singleton has synchronized parts, there are reasons for that too.

If you separated the thing into multiple instances, would you not have to come up with even more complicated and less efficient means of coordinating their efforts?

Of course, if the singleton doesn't really need to be a singleton, or if the synchronization is not really needed, that simplifies the question, but I'm assuming there were reasons for these choices.

I don't think there is any rationale for saying that a singleton implementation of something is inherently worse when there are more users of it. In fact, it may be better, since there won't be a lot of extra object creation (extra in the sense that if it can be done with a singleton, then all the creation of non-singleton objects seems kind of superfluous). After all, whether you have one object or a thousand, it it still running on one machine (assuming we're not getting into discussions about clustering, here).

By the way, a singleton could have maintain thread pool for tasks so that it could run more than one at the same time.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 1, 2004 3:19 PM

Reply

Oops, a typo there! That last sentence should be something like this:

By the way, a singleton could have a thread pool for tasks so that it could run more than one at the same time.

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 1, 2004 11:01 PM

Reply

Hmm..

I dont say that you should not use Singleton pattern if you need it. But yes, inherently it suffers from or is a bottleneck for a highe performing system as access to a system is through a single point.

Imagine you have number of co-operating processes running in a cluster and still your request has to go through a single object. Imagine each distributed client having have to first get reference to that singleton object??

If you are doing pooling of objects then that is not your singleton object right? . And more suitable to be part of Factory pattern to do object pooling.

When we talk of better designs one of the thing that needs to be considered is that you should not create blogs, i.e. an object having most of the responsibilites. Should avoid controller patterns etc.

Object should communication should be peer to peer, thorugh well defined interfaces.

Singleton is just one of the creation pattern, allows to have you greater control etc..but is liable to mis-use.

Use it if you really need it. But avoid it where you can with better designs.

regards,
Shashank

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 1, 2004 11:04 PM

Reply

If you want to create multiple thread to do tasks within an object?

You should validate against other design priniciples like, why not to create multiple objects.

Why not to do pooling of objects to do the same..

there are many other principles that can be explored instead of creating threads to do multiple tasks. Thought technically possible but then it defeats the intention of having singleton pattern.

Kishori Sharan

Posts: 211
Nickname: kishori
Registered: Feb, 2002

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 2, 2004 3:48 PM

Reply

There is no such limitations on number of callers for getInstance(). I would suggest you not to synchornize getInstance() method to avoid overheads. Rather, use static field and create the instance there itself.

public Class Singleton {
  private Singleton instance = new Singleton();
  // ...
  public Singleton getInstance() { // Don't synchronize
   return instance;
  }
}

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 3, 2004 1:25 AM

Reply

Limitation doesnt comes because clients are not allowed to get instance of singleton object. Limitation comes because of processing the request for demand for this object when larger number of clients are there.

If required you should use it and why not?

But if you don synchronize it, it is possible to create multiple instances of object at some point of time. Then why singleton pattern?

Though you may not need to declare the method as public static synchronized. You may use more optimized menchanism, but point is still some processing is to be done?? and for what? just to get the access the object, and if you are handling or upating some state information, the complexity involved in simlutaneious execution trying to update the state, is high.

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 3, 2004 9:09 AM

Reply

This approach will work fine, if the Singleton Class doesnt have heavy states.

Also by creating the instance before being sure of when and whether it will be used is not better design.

Again, assuming everything is fine, what about, the methods that will be called, are they synchronized properly?

Making a thread safe singleton class with lots of states islittle bit complex. Thats all.

Many only intention is to say that be open for other options to explore instead of having an "I have to use singleton class" attituted.

rergards,
Shashank

Kishori Sharan

Posts: 211
Nickname: kishori
Registered: Feb, 2002

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 3, 2004 11:35 AM

Reply

Shashank
First let me correct my post: I missed static keywords in both places in variable declaration and getInstance() method.

You have started discussing something that was not mentioned in the original post at all. The question was: Is there any limitations on number of callers as far as getInstance() method is involved. That's all the question was. The answer is "No". The overhead of calling getInstance() method can be removed by not synchronizing it and creating the object instance while declaring the static field. That's all the answer should be. I don't understand why you would start explaining about apple if someone asked explanation on mango. I understand other guy who replied to your post. He is just like that. Most of the time he talks about Python and Gython when someone asks question about Java. I have seen many good posts from you. My advise to you that just ignore that guy who just wants to make fun of others.

I will answer your questions which you have raised in your posts:

--But if you don synchronize it, it is possible to create multiple instances of object at some point of time. Then why singleton pattern?

Answer: There will be only one instance all the time no matter how many users are calling it simultaneously. Because, the instance is created only once when class is loaded for the first time.

--Though you may not need to declare the method as public static synchronized. You may use more optimized menchanism, but point is still some processing is to be done?? and for what? just to get the access the object, and if you are handling or upating some state information, the complexity involved in simlutaneious execution trying to update the state, is high.

Answer: Since the original question doesn't mention anything about the state of its object - heavy/light, all these explanations are irrelevant in this context.

--This approach will work fine, if the Singleton Class doesnt have heavy states.

Also by creating the instance before being sure of when and whether it will be used is not better design.

Answer: With the approach I have mentioned and with the Singlton Pattern, the instance will be created when it is needed for the first time. Since instance is created when class is loaded, it will be created when yo call its getInstance() method first time. Here is a catch: If the class developer doesn't use the proper semantics of having a Singlton pattern then he may have some static methods other than getInstance() and the call to that methods will also create the object. However, that will happen only when someone is trying to use Singlton pattern in a wron way.

-- Again, assuming everything is fine, what about, the methods that will be called, are they synchronized properly?

Answer: Again, you are speculating about its use. Only the developer who posted the question originally can answer this question if that is the case. And, if he has to have a shared resource, which can be modified by many users and must be synchronized then it must be synchronized. The optimization techniques depends on the situation at hand.

--Making a thread safe singleton class with lots of states is little bit complex. Thats all.

Many only intention is to say that be open for other options to explore instead of having an "I have to use singleton class" attituted.

Answer: Again, I will say that I don't want to comment on somethng about which I don't know. Just look at your comment: "Making a thread safe singleton class with lots of states is little bit complex." Does it serve any purpose to anybody who reads it. Your statement sounds like a politian statement.

On a forum, it is essential that you keep your answers focussed on the original question. If you want to give some extra information then make it brief and complete. Don't answer a question just because you want to answer it.
Developers from around the globe will be spending time to read it. The very purpose of your taking time and answering the question is defeated if it doesn't help someone.

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 3, 2004 10:15 PM

Reply

Hi Kishori,

Thanks for you patience for going through each line and replying to each of the thing that I said.

But I fail to understand where did I deviated from original quote??

Limitation of any idioms or constructs doesnt comes because you want to use them, but because the way you want to use them. And this way is always dependent on the contextual information.But if the context is not mentioned in detail, what to do?

You cant simply tell that this is good, or has limitation or whatever. You should site the contexts where it has limitation. This is what I have done, have sited the context where if someone wants to use singleton it may limit the performance etc. of the programme.

I have not sited single instance of contexts where Singleton is useful!!!

One should read the article available at the following link:It talks about when to use singleton and other benefits.
http://java.sun.com/developer/technicalArticles/Programming/singletons/

Now coming to original quote:
The question was: Is there any limitations on number of callers as far as getInstance() method is involved. That's all the question was.

The answer is "Yes".

Singleton forces uses of single entry to the system. Why will I not have several gateways for my system?

So what I sited was instance where it may not be useful or is a bottleneck.

All this become more important to be considered esp when you are talking about distributed systems? How do you ensure singleton behaviour now when I can take the class and instantiate it on all the systems? And again this is not mentioned in the original quote whether someone wants to develop distributed system or centralized programmes???

All these are just to tell the users of singleton that they are limitations to uses of singleton (and this is what was asked for).

And whether this limitation really applies to the context where and the way developer wants to use is...is..I dont know!! He has to figure it out. And see that his preference for this particular design is justified.

regards,
Shashank

Kishori Sharan

Posts: 211
Nickname: kishori
Registered: Feb, 2002

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 4, 2004 9:49 AM

Reply

Shasanka, with due respect, I would like to differ with you on some of your points.

--Now coming to original quote:
The question was: Is there any limitations on number of callers as far as getInstance() method is involved. That's all the question was.

The answer is "Yes".

Singleton forces uses of single entry to the system. Why will I not have several gateways for my system?

:: The answer "yes" should be rephrased here. If you make getInstance() method synchronized and go for laziy instance creation (which you don't have to) then only answer is "yes". Otherewise, answer is "No". I don't understand what do you mean by using the word "system" in: "Singleton forces uses of single entry to the system. Why will I not have several gateways for my system?". Singlton only allows one access point to get hold of the reference of the instance. That's all. Once you have a reference do whatever you want to do with it according to your class design. If you don't make getInstance() synchornized then multiple threads can call it simultaneously and they can have the reference to its instance at the same time. So there is no question of having one entry point. You are trying to give impression as if Singlton means: one instance of a class and only one caller can work with that instance at a time. However, singlton means only one thing and that is : There must not exist more than one instance of that class.

If someone wants to have singlton like design in an app server, then he should be using a shared component, which will have only instance even in clustered environment.

Thanks
Kishori

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 4, 2004 10:24 AM

Reply

Hi Kishori,

Am not sure if you are upto fair discussion about limitations of singleton object.

--------
In this reply am not quoting advantages of singleton objects, doesnt mean that they dont offer some obvious advantages. So with this in mind go ahead read rest of the quote.
---------

Am not at all against usage of singleton as such. It was all about highlighting issues/limitations in terms of both design (good/bad), context (when) and in general when singleton is a limitation.

As u wil agree that better design prinical is to prefer lazy initialization of objects, which in the way of constructing singleton object (as shown by you) is not justified. But in some case it is.

Similarly, I was referring to multiple entry point to my system, system could be anything my app server, a web site, a data base, or simply another object. When you have collaborating processes in a cluster, it doesnt makes much sense to limit the number of entry points. If 5 objects in the system are capable of serving my requests why to route all the requests through one object(and only one object)? But yeh for something like facade its fine, even then you should justify it.

These are just some of the issues. Other issues related to singleton is managing lifecycle (particularly its destruction) of a singleton object is a bit complex.

Moreover if you are using singleton in servelet environment dont be surprised if you get some surprising results!!

Not only but the following evils happen to your design when u use singleton

1. Sub system's coupling to Singleton's Class Name.

2. Singletons aren't polymorphic.

3. "All of a sudden there are two types of objects, those that can be instantiated in a standard fashion and those that cannot be created at all".

4. "The singleton also doesn't have to instantiate the object. It just has to provide access to the object. The object returned can bet set by any means necessary."

So, in my opinion, Singleton or for the matter any design principal is never good/bad has limitation in itself. but always the way it is supposed to be used.

Singleton as mentioned above, not only puts limitation in performance, but to extending the current design itself. How can you ensure that current singleton objects behaviour can be extended without much change? In both its class as well as all the clients of it??

And now what is this shared component you have brought forward? Are you aware what it takes to provide singleton objects behaviour in a cluster??

In my opinion Singleton is a nice object creation pattern but like anything else, is liable to be misused. So site contexts, consider design pricipals and pros and cons and then go for whatever you decide.

Ultmately we have to be responsible for not only object creation but its maintainence as well.

hope this helps,
regards,
Shashank

Shashank D. Jha

Posts: 68
Nickname: shashankd
Registered: May, 2004

Re: Concurrent Singleton usage - Limitations ?

Posted: Jul 4, 2004 10:31 AM

Reply

Hi ALL,

Whoever wants to really consider design prinipals before using singleton pattern do go through following article:

http://www-106.ibm.com/developerworks/webservices/library/co-single.html

->It mentions how using singleton pattern, with time leads to Antipattern.

->It makes testing difficult.

->How by using singleton class, a client implicitly becomes tightly coupled with a class (not with its type).

->And it discussed some points when to go for singleton and when to avoid it.

regards,
Shashank

Flat View: This topic has 16 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use