what is synchronized singleton ?

[Ranga Kalidindi]

What is "a synchronized singleton" ?
And pls suggest how to implement this so that the signleton does not get duplicated per processor ?

[jayram joshi]

Can you give some context about where you faced this issue? Singleton has got nothing to do with how many processors your system has.
[ October 26, 2005: Message edited by: jayram joshi ]

[Stuart Ash]

It's possibly this: a singleton whose factory method is synchronized.

  
public class Someclass
{
  private Someclass(){}
 
  public synchronized Someclass instance()
  {
    //return the only instance
  }
}

[Ranga Kalidindi]

Actually I have singleton implementation of a class (it is a cache where I hold my application reference data). One of my designer had a comment like this "Why is the cache not a synchronized singleton so that the cache does not get duplicated per processor? (This is a logic error that must be corrected otherwise the application will fail)".

I thought may be I missed something while implementing a singleton.

Thanks Stuart, probably that is what my reviewer was expecting.

thanks All.

[Srinivasa Raghavan]

Will you be running two seperate instances of your application at that same time. In that case i think you 'll get two objects of your singleton class. Since the applications are launched seperately.

The problem is because of two java processes are run in 2 seperate JVM's . Here you need to do some thing like interprocess communication.
[ October 26, 2005: Message edited by: Srinivasa Raghavan ]

[Scott Selikoff]

Yeah, one thing I still remember for the SCJP is that synchronized refers to methods accessing an object, there's no such thing as a sychronized object.

You can define multiple singletons in a JVM in J2EE since different tasks can have different class loaders. If this is the case read up on class loaders in J2EE.

Otherwise, if the JVMs are the same, the singletons are the same.

[Tony Morris]

Aside from the less obvious fact that a singleton is an implicit requirement defect, it might yield some insight by reflecting on the statement "You can define multiple singletons" with emphasis on the term "multiple singletons". Spot the contradction in requirements?

Granted, the JLS does talk about "constant variables" or was it "variable constants"? so all bets are off with respect to making sense

[Richard Anderson]

Originally posted by Tony Morris:
Aside from the less obvious fact that a singleton is an implicit requirement defect, it might yield some insight by reflecting on the statement "You can define multiple singletons" with emphasis on the term "multiple singletons". Spot the contradction in requirements?

Granted, the JLS does talk about "constant variables" or was it "variable constants"? so all bets are off with respect to making sense

Are you saying that by using Singletons, you're using an antipattern?

[Tony Morris]

Originally posted by Richard Anderson:


Are you saying that by using Singletons, you're using an antipattern?

Of course!
It's not obvious? Put the glossy brochure down and obtain the facts. Here are some that I suggest to start with; GoF is not an authoritative source of Truth(TM), neither are those books that spawned off it. The marketing campaigns of large multi-national corporations have an agenda to obscure the truth to meet their financial objectives (did you see the JDK 5.0 marketing material? Was it 'truthful'?).

http://www.google.com/search?q=singleton+antipattern

Good luck.

[Richard Anderson]

Ok, aside from pointing to a link to Google that attempts to defend your position, which I may note, I can do with almost any search term, EXPLAIN to me why YOU think it's an antipattern.

[JuanP barbancho]

HI,

I think that singleton use in order to do not make more than one instance of object.

Syncronized use in order to do no access to an object from different thread.

It is posible use a singleton for have only one instance and syncronize the use of this. Ej sychronize the access to singleton or the best, only the part that you need sychronize.

I think that Filosophie discursion about parttern and antiparttern is for consultant, developper must point to solution.

Thanks

[Scott Selikoff]

Aside from the less obvious fact that a singleton is an implicit requirement defect, it might yield some insight by reflecting on the statement "You can define multiple singletons" with emphasis on the term "multiple singletons". Spot the contradction in requirements?

Welcome to Class Loaders in J2EE, please leave common sense at the door!


Some thoughts...

Unless you're extremely careful in J2EE its possible to define singletons accross an EAR only, that you meant to define accross the entire server or visa versa. This is still assuming only one JVM. Anyone defining a singleton on a J2EE should be extremely careful how/where the libraries are loaded. BTW- there are more than just 2 class loaders, so it can even be more complicated than this.

For example, you may have the JAR file in each EAR and define an EAR-level singleton using this JAR. An administrator may think "wow, since this JAR is in every EAR, I'll copy it to the server library directory." They've just changed the behavior of the singleton throughout the server. Of course, a careful administrator could also change the class loading order for the EAR ('parent first' or 'parent last'), but again this requires detailed knowledge of how the singleton is used.

[Scott Selikoff]

One other thought on J2EE and singletons... although you can use singletons in J2EE, it is not the recommended standard. Since one of the most common uses of a singleton is for caching for example, it is recommended you use some kind of standard caching mechanism available on the server. There are other such standards that are situation dependent where you can replace singletons with a more advanced model.

Although *personally* I find a lot of the alternates to be very proprietary. For example when working in WebSphere, IBM consultants tried to steer us toward IBM-specific solutions which I found dangerous since the more you depend on them, the less portable you are. Singletons are often faster and simpler than anything out there but they require very good understandings of server class loading and are sometimes too delicate.

[Tony Morris]

Originally posted by Scott Selikoff:
One other thought on J2EE and singletons... although you can use singletons in J2EE, it is not the recommended standard. Since one of the most common uses of a singleton is for caching for example, it is recommended you use some kind of standard caching mechanism available on the server. There are other such standards that are situation dependent where you can replace singletons with a more advanced model.

Although *personally* I find a lot of the alternates to be very proprietary. For example when working in WebSphere, IBM consultants tried to steer us toward IBM-specific solutions which I found dangerous since the more you depend on them, the less portable you are. Singletons are often faster and simpler than anything out there but they require very good understandings of server class loading and are sometimes too delicate.

When I started reading this, I thought you might be referring to JNDI, but then you started talking about a WebSphere-specific solution. A singleton is only ever used to replicate the behaviour of global data, which always has a better approach (typically, a callback as a more appropriate abstraction). I'm not going to provide a complete reasoning here, for the same reason someone else wouldn't provide me with a complete reasoning why the sky is blue - it's pretty obvious with some simple objective analysis.

Curious, what WebSphere-specific solution are you referring to?

[Ronnie Ho]

Tony,

A singleton is only ever used to replicate the behaviour of global data, which always has a better approach (typically, a callback as a more appropriate abstraction).

Do you have "link" for more info about the "callback" that you mentioned above? I've read something on the internet, but am not sure how that would be a replacement for singleton. Thanks.

[Scott Selikoff]

Curious, what WebSphere-specific solution are you referring to?

Honestly, I don't remember. I tended to tune out the IBM consultants when encouraged us to use proprietary non-standard solutions. It was basically an IBM jar library for caching. Sort of goes against the notion of J2EE being fully portable since if you use it your even more stuck with WebSphere than you were before.

As an example, one of the common patterns that was encouraged was to never write local facades for any EJB beans solely because WebSphere has an optimization technique that will detect whether or not a remote facade is truly local or not, and if so, avoid serialization calls for remote facades, therefore treating them as local. I don't honestly know how widespread this type of practice is, but it always left me a little unsettled to be basing so much solely in their technology.