Announcement Announcement Module
Collapse
No announcement yet.
Definition of Spring "singleton"? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Definition of Spring "singleton"?

    Hi, everyone.

    I've looked through the documentation at Spring and in my books (Spring in Action and Pro Spring), but I can't find a clear definition for Spring's use of the word "Singleton".

    Is this a per-JVM singleton? per-thread singleton? or per-ApplicationContext-instance singleton? (There could be subtle but important differences here, regarding the classloader andThreadLocal.)

    Please just point me to the doc where this is explained, if I'm just missing something simple.

    Ben

  • #2
    Hi Ben

    In the context of Spring, the 'singleton' that is referred to is a 'per-ApplicationContext-instance'.

    http://static.springframework.org/sp...-factory-modes

    Cheers
    Rick

    Comment


    • #3
      Thanks, Rick. Reading over the doc you showed, the answer still looks murky to me. Is that your opinion, or do you know that for sure? If so, how?

      ...or did I miss a significant phrase in the doc?

      Ben

      Comment


      • #4
        Originally posted by Rick Evans
        In the context of Spring, the 'singleton' that is referred to is a 'per-ApplicationContext-instance'.
        What about these in the same context?
        Code:
        <bean id="bar1" class="com.foo.Bar"/>
        <bean id="bar2" class="com.foo.Bar"/>
        Shouldn't those be two instances as well?

        Comment


        • #5
          per-ApplicationContext-instace for one bean. In your case you'll have two singletons - i.e two shared instances of the same class, one under bean bar1 and one under bar2.

          Comment


          • #6
            Btw, for more info see some of the 'red' books from the main site - they offer a lengthy but thorough explanations on Spring and j2ee concepts.

            Comment


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

              Thanks in advance.

              Comment


              • #8
                If all your applicationContexts are already sharing the singleton then all you have to do is get a hold of a context and simply request the singleton by its bean name.
                I think the problem is how to create multiple application contexts that share the same beans (i.e. you have a hierarchy of contexts distributed across different VMs). Right now there's no out of the box support in Spring and I think you have to use some commercial products which offer 'transparent' clustering to be able to do this.

                Comment


                • #9
                  Originally posted by Costin Leau
                  per-ApplicationContext-instace for one bean. In your case you'll have two singletons - i.e two shared instances of the same class, one under bean bar1 and one under bar2.
                  Exactly - that's the point I was implying. Strictly speaking, it's not even per-ApplicationContext-intance, it's per-ApplicationContext-instance-and-per-bean. IMHO, the difference here is significant, theoretically at least.

                  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", "a clustering singleton" means "one instance for this class throughout the 'world'". But in the context of Spring, that assumption isn't necessarily true any more - Spring does not distinguish or manage beans by their classes, but by ids or names. So, singleton="true" actually has some very different semantics from the usual singleton concept we as Java programmers have taken for granted.

                  That may well seem to be some "hair splitting", but I think it can get very confusing especially for new Spring users.

                  Comment


                  • #10
                    Exactly - that's the point I was implying. Strictly speaking, it's not even per-ApplicationContext-intance, it's per-ApplicationContext-instance-and-per-bean. IMHO, the difference here is significant, theoretically at least.
                    Fair dues... I agree that defining Spring's concept of a singleton in 100% clear, authoritative and unambiguous terms is important, and the reference doc section is not '100% clear, authoritative and unambiguous'.

                    I'll address this in the 2.0 final timeframe. Feel free to chip in with suggested text

                    http://opensource.atlassian.com/proj...rowse/SPR-2124

                    Cheers
                    Rick
                    Last edited by Rick Evans; Jun 12th, 2006, 01:27 AM.

                    Comment


                    • #11
                      Originally posted by olope
                      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

                      Comment


                      • #12
                        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.

                        Comment


                        • #13
                          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

                          Comment


                          • #14
                            Ok, so I can't count to four

                            Comment


                            • #15
                              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.

                              Comment

                              Working...
                              X