Announcement Announcement Module
Collapse
No announcement yet.
Singleton beans instantiated multiple times Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Singleton beans instantiated multiple times

    I'm seeing beans that are marked as singletons being instantiated multiple times and I can't figure out why.

    I'm using the custom XML schema based configuration so I'm doing all the parsing and and setup of the beans myself. My application contains a "global" application context where certain large components are initialized.

    These components, during their initialization process, create a new generic application context, passing in the global app context, and then parse their own spring configuration files. So the code looks something like this:

    Code:
    GenericApplicationContext newServiceContext = new GenericApplicationContext(getApplicationContext());
    
    SpringConfigurationUtils.populateRegistry(newServiceContext, getServiceConfigurations());
    where SpringConfigurationUtils.populateRegistry just loads in some number of configuration files via a standard XmlBeanDefinitionReader.

    Some of the components created in the global context depend on other ones created in that context. Despite the fact that each of these components are marked as singletons, I see new instances being created for each injection.

    For example, least assume Components A, B, C with B & C depending on A and all three being created in the global application context. I see A instantiated first (as I'd expect) and then I see B instantiated. However, when the Spring container goes to inject A into B, I see A get instantiated again. Same for when the Spring container is build up C.

    Can of the Spring gurus out there help me track this down? I don't even know enough about the problem yet to know where to look in the code.

    Thanks for the help.

  • #2
    Actually, I just thought of something. I'm not setting the singleton flag on all the beans created within those components. Is prototype the default scope? if so, wouldn't this mean that Spring would create an entirely new instance of those components if any of the beans within it were of prototype scope?

    Comment


    • #3
      I'm not sure what this SpringConfigurationUtils is supposed to do. Can you give a link to it's javadoc (are you using edu.internet2.middleware.shibboleth.common.config. SpringConfigurationUtils)?

      http://static.springframework.org/sp...factory-scopes states that singleton scope means that there will be one instance per container so if you're creating multiple containers you should expect to get multiple instances (one for each container). Could this be what's happening?

      Comment


      • #4
        Yes, it's the SpringConfigurationUtils from Shibboleth. As I mentioned, all it's doing is just reading in the configuration files and loading them into the container through an XMLBeanDefinitionReader.

        I'm not sure what you suggested is what is occuring or not. As I said, I don't know the Spring code well enough to know if that is what is occuring. It may well be, but if it is I'd see two issues with that:
        - I'm only creating one instance, in the global context and that's all I want
        - If what you suggest is occuring, why would one context be able to have another context as a parent? Obviously it wouldn't be inherting any bean information from it.

        One question may be, does a context == container? My understanding was that it did not. That instead the container was the thing that held the collection of instantiated contexts, performed lifecycle management, etc. But, like I said, I don't know the Spring code well enough to know.

        Comment


        • #5
          How did you find out that your singletons are instantiated multiple times? Couldn't you debug and see which statement leads to that? A possible source of multiple instances is Spring AOP with CGLib.

          Joerg

          Comment


          • #6
            While the custom schemas are being parsed to create new beans I log a lot of the configuration information. So, for example, one of those larger components I mentioned has, on average, 15-20 beans that get created. When the system starts up I can see the log messages within those 15-20 beans repeated when Spring creates a second or third instance of them.

            Comment


            • #7
              Are you sure, that
              Code:
              GenericApplicationContext newServiceContext = new GenericApplicationContext(getApplicationContext());
              is called only once?
              And what getApplicationContext() does?


              Regards,
              Oleksandr

              Comment


              • #8
                u want to use prototype

                singleton does make a new instance for every object use...if you only want one instance for doing manager like functions (ie container holding a data set for the app) you should be using prototype. That will only make one instance. Use prototype when you want to save state.

                Singleton in spring is not the same as singleton pattern.

                Correct me if I am wrong anyway,somewhat new to spring myself...here is the link I read for this....

                http://static.springframework.org/sp...nce/beans.html

                look under 3.4 bean scope...

                Comment


                • #9
                  You are wrong absolutely and completely. As far as I can see you have heavily misunderstood documentation.

                  From the same document:
                  3.4.1. The singleton scope

                  When a bean is a singleton, only one shared instance of the bean will be managed, and all requests for beans with an id or ids matching that bean definition will result in that one specific bean instance being returned by the Spring container.
                  ..........
                  3.4.2. The prototype scope

                  The non-singleton, prototype scope of bean deployment results in the creation of a new bean instance every time a request for that specific bean is made (that is, it is injected into another bean or it is requested via a programmatic getBean() method call on the container).
                  And note that the only difference between Spring singleton and "classical" implementation of GoF singleton is that Spring singleton has one instance per bean id and container and GoF singleton - per class and classloader.


                  Originally posted by kramik1 View Post
                  singleton does make a new instance for every object use...if you only want one instance for doing manager like functions (ie container holding a data set for the app) you should be using prototype. That will only make one instance. Use prototype when you want to save state.

                  Singleton in spring is not the same as singleton pattern.

                  Correct me if I am wrong anyway,somewhat new to spring myself...here is the link I read for this....

                  http://static.springframework.org/sp...nce/beans.html

                  look under 3.4 bean scope...

                  Comment


                  • #10
                    wow so much for tacit...

                    Comment


                    • #11
                      Originally posted by kramik1 View Post
                      wow so much for tacit...
                      If you want to see tact, you should go over to the hibernate forums... but I think you got prototype and singleton mixed up, that's all. That means you got it *exactly* wrong, which is often much better than having it almost right. No pun intended.

                      Just quickly edit your post and switch "singleton" with "prototype"; you'll make us all look stupid .

                      Comment


                      • #12
                        opps my bad

                        I didn't notice the edit function before....

                        As long as you learn from your mistakes right?

                        I had read up on the singleton versus prototype for a manager that I am making. There should only be one manager that holds stateful objects for the application. I read that stateful objects should be prototype and stopped. I didn't read far enough to see that the manager should be singleton and the object it holds should be prototypes.

                        Getting back on topic, did anyone figure out his problem?

                        Comment


                        • #13
                          Originally posted by kramik1 View Post
                          I didn't notice the edit function before....

                          As long as you learn from your mistakes right?

                          I had read up on the singleton versus prototype for a manager that I am making. There should only be one manager that holds stateful objects for the application. I read that stateful objects should be prototype and stopped. I didn't read far enough to see that the manager should be singleton and the object it holds should be prototypes.

                          Getting back on topic, did anyone figure out his problem?
                          The difference between prototype and singleton is not "stateful" against "stateless". You may have stateless prototype (which is rarely, if ever, sensible) and you may have stateful singleton (to keep global state).

                          The real difference is that for singleton each fetch from context return the same instance of objects and for prototype - new one. IT hold as well for fethes that occur during context initialization. For example
                          Code:
                          <bean id="myPrototype" class="mumu.Prototype" scope="prototype"/>
                          
                          <bean id="singleton1" class=... scope="singleton">
                              <property name="someProperty" ref="myPrototype"/>
                          </bean>
                          
                          <bean id="singleton2" class=... scope="singleton">
                              <property name="someProperty" ref="myPrototype"/>
                          </bean>
                          singleton1 and singleton2 hold different instances of mumu.Prototype.

                          Note as well that beans are injected only once - on creation, i.e. subsequent fetches of that singleton from context would return the same instance of singleton holding the same instance of prototype (unless you reinject its programmatically).

                          So if your stateful-objects keep information that is global for the application they perfectly may be singletons.

                          Comment


                          • #14
                            Originally posted by kramik1 View Post
                            I didn't notice the edit function before....

                            As long as you learn from your mistakes right?

                            I had read up on the singleton versus prototype for a manager that I am making. There should only be one manager that holds stateful objects for the application. I read that stateful objects should be prototype and stopped. I didn't read far enough to see that the manager should be singleton and the object it holds should be prototypes.

                            Getting back on topic, did anyone figure out his problem?
                            I'm not sure, but it sounds like you're running into one of the fundamental problems of application development: Who is doing the work?

                            I wager that you're using the manager to do the work, but it seems likely to me that what you're thinking of managing is actually perfectly managed by the jvm's garbage collector on the one hand and the user of your application on the other hand.

                            In most of the cases it makes perfect sense to instantiate objects inside methods on your singletons without a "manager" in the middle.

                            Comment


                            • #15
                              I would say that manager in the middle is the most fundamental problem of software development process
                              Originally posted by iwein View Post
                              I'm not sure, but it sounds like you're running into one of the fundamental problems of application development: Who is doing the work?

                              I wager that you're using the manager to do the work, but it seems likely to me that what you're thinking of managing is actually perfectly managed by the jvm's garbage collector on the one hand and the user of your application on the other hand.

                              In most of the cases it makes perfect sense to instantiate objects inside methods on your singletons without a "manager" in the middle.

                              Comment

                              Working...
                              X