Definition of Spring "singleton"?

[benethridge]

Is there a wat to obtain a singleton shared by all ApplicacionContext-instances?

Th reason I asked my original question is similar to the above:

Is there a way to obtain a "per-thread singleton"? i.e a singleton shared by all ApplicationContext instances associated with the SAME THREAD (as opposed to the same JVM or "cluster")?

Reason I ask is that we don't want to have to inelegantly "pass around" (via method parameter, constructor or setter/getter) the ApplicationContext object any more than we wanted to pass around the Spring objects themselves in this other forum thread:

http://forum.springframework.org/sho...7&postcount=37

...and:

http://forum.springframework.org/sho...1&postcount=39

...within the forum thread:

http://forum.springframework.org/sho...t=24569&page=4

Ben

[Rod Johnson]

Outside Spring, whenever we talk about singletons, there is always an assumption that we are talking about how many instances are there per class - "a per-JVM singleton" means "one instance for this class throughout JVM".

Actually, it means per classloader--a subtle but sometimes important difference.

[benethridge]

Reading over this forum thread, and others like it, IMHO I believe the java world needs three levels of "singleton scope", if we can call it that:

(1) Per-application-context-instance singleton scope.

From the Spring responses to this forum thread and my own observations running my app, it appears to me that this is currently the only level available in Spring. In this one, if you instantiate two ApplicationContext objects, they will each have NEW AND DIFFERENT bean objects ("bean objects" being the beans in the application config xml file).

(2) Per-thread singleton scope.

This is what I currently need and what I was able to create using TransactionDispenser, as discussed in this forum thread:

http://forum.springframework.org/showthread.php?t=24569

In this one, if you instantiate two ApplicationContext objects IN THE SAME THREAD, they would both share the same bean objects.

(3) Per-JVM singleton scope

In this one, if you instantiate two ApplicationContext objects IN THE SAME JVM, they would both share the same bean objects.

This would be one that solves the classloader subtlety Rod and I mentioned. I'll upgrade it from a "subtlety" to a "problem" because I imagine that few developers actually WANT a classloader-level singleton, compared to the number of them who want a rock-solid reliable easy-to-use true "per-JVM singleton" (including myself).

(4) Global or "per-cluster" singleton.

If I'm understanding what Costin meant earlier in the forum thread, this would be a singleton that crosses JVM boundaries, in that only one is ever instantiated for the entire "cluster" (however that ultimately gets defined). In this one, if you instantiate two ApplicationContext objects IN ANY JVM IN THE CLUSTER OF JVMS, they would both share the same bean objects.


Spring seems like a great framework for supplying these to the java world, since I'm guessing it already knows and controls most of the pieces via the ApplicationContext and DI/iOC. Perhaps this could be a feature for an upcoming release?

Ben

[benethridge]

Ok, so I can't count to four

[Costin Leau]

This would be one that solves the classloader subtlety Rod and I mentioned. I'll upgrade it from a "subtlety" to a "problem" because I imagine that few developers actually WANT a classloader-level singleton, compared to the number of them who want a rock-solid reliable easy-to-use true "per-JVM singleton" (including myself).

Just to clarify things a bit:
inside the VM a .class is defined by it's bytecode and the classloader that loads it. So if you have definition for A.class, inside the VM you can have the same class definition loaded multiple times by different classloaders.
So there is no 'true' per-JVM definition - if inside the same VM you have multiple classloaders, there can be multiple "singletons" since there are different representation of the same class. It is perfectly legal actually.

Basically, the true/original is the singleton per classloader (i.e. per .class). The rest are subsets, with limited scope.

[benethridge]

Hi, Costin.

I understand, but in the world of day-to-day java app development, the per-classloader singleton is pretty useless, wouldn't you say?

I mean, google up "java singleton pattern", and notice how the classloader issue is "deceptive", and a "pitfall". It is something to be worked-around, not a desired feature of the conceptual pattern. Example:

http://www.javaworld.com/javaworld/j...npatterns.html

Other authors (from the google) talk about the threading problem that one has to work around and the cloning problem that has to be worked around, but interestingly, not the classloader problem (maybe coz there is no reasonable work-around?) :

http://www.javacoffeebreak.com/artic...rns/index.html

Other authors don't even mention ANY problems, saying only that it's "simple":

http://www.onjava.com/pub/a/onjava/2...singleton.html

IMHO, what day-to-day app programmers are usually looking for are frameworks like Spring, which abstract away some of the "deceptive"s and the "pitfall"s of java, so they're free to concentrate on the higher-level patterns, patterns (like the 4 stated above) which would allow them to quickly and reliably write their application-level code.

Ben

[Costin Leau]

I'm not arguing about the usefulness of the singleton pattern; I'm just trying to clarify this .

[benethridge]

I understand. Thanks.

Ben