Announcement Announcement Module
No announcement yet.
Context size Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Context size

    Does the growing size of the context have any impact on the performance of spring ?
    Is there any maximum number of bean to put in the context ? Do you have any metrics for that ?



  • #2
    I don't think anybody has collected any hard metrics on this specific area. People have done benchmarking on things like transactional wrapping for example, witht he proxy coming from a context, and the impact was minimal, but those would not have been incredibly large contexts.

    Past the initial load, all the data related to definitions is accessed from a hash, so the impact of a larger context vs. a smaller one is minimal. Additionally, most people run with most beans in the context as singletons, so beans have already been pre-instantiated at time of load, unless overriden.

    For prototypes, one thing I can see having some measurable impact is the use of BeanNameAutoProxyCreator to create proxies, and the list of bean names runing to the hundreds or more. The issue here is that when you ask for a (prototype) bean, the auto proxy creator will run through its entire list of bean names each time (they can not be hashed as they are wildcarded), to see if there is a match and the bean should be wrapped. This would really be a concern only if you were getting a lot of prototypes (effectively replacing new), and using the auto proxy creator to wrap a lot of beans. I personally prefer using 'template' parent bean definitions along with child bean definitions, to create proxies, over BeanNameAutoProxyCreator.


    • #3
      I've not seen any issues in practice, including in large apps. Colin's discussion covers the technical issues I can think of.

      Note that Spring MVC includes support for avoiding one huge context, through multiple contexts (one per dispatcher servlet) with a common parent. In other kinds of apps, it also probably makes sense to break up contexts for manageability, rather than because of any limitation re context size.


      • #4
        recommended "how to" on multiple application conte

        I'm starting to implement Spring into our existing codebase. We have 2 swing apps and a web app that all have some shared code... let's say in shared.jar. My current enhancement only needs to modify shared and 1 of the swing apps. I think it would be best if break up the spring context xml into springapp1.xml and springapp-shared.xml (with test versions of both).

        So my question is, what's the appropriate way for my application code to make calls to shared classes? Should I included a "sharedApplicationContext" bean in my app xml and use it to set a property on a shared class... and then have the shared class use it's ApplicationContext property to get other classes from the shared jar?


        • #5
          There's a few different ways to slice this. I would always try to avoid the situation where user code actually gets a context and gets beans out of there, unless strictly necessary (i.e. it's glue code which needs to kick off something).

          What I've done a decent amount of on the past is a couple of strategies:

          1- share code, but have a distinct context for each app.


          2- each module has its own xml fragment or fragments that get assembled in the final app along with fragments from other modules, into one context. You resolve the situation where more than one module needs the same resource, by having each module refer to it by a module specific name, and then in the xml file fragment for the app itself, you define that resource, and also give it aliases so the other modules can find it. e.g.
          Module1 refers to the datasource as
          Module2 refers to the datasource as
          and the datasource is actually defined in an xml fragment for the app (that is combined with the module fragments) as
          but it's give the other two names as aliases...


          • #6
            multiple xml files

            For option 1, where the shared code has its own context, I assume that the entry point classes in shared.jar need to lookup there own ApplicationContext?

            For option 2, can Spring assemble the fragments? If so, how (or where to look)? Or otherwise is there some utility to do this that already exists out there?


            • #7
              For option 1, what I meant was that the appcontext would be completely separately defined for each app, so the only thing that modules would contribute would be classes. I'm not sure I know what you mean by 'entry point' classes. Ultimately, if classes are used in an IoC fashion, they may not need to know anything about the container at all. Alternately, glue code and the like from the module could can also be ApplicationContext aware so it knows about the context.

              As for option 2, when you create an application context, you can specify (in the constructor, and also when using variants like the ContextLoader for web-apps) multiple fragments, which will be combined into just one context.


              • #8
                multiple xml files

                Option 2 sounds preferable to me at this point...

                WRT entry points: I was just referring to something like
                AppClass {
                public void setShared(Shared shared) {
                this.shared = shared;
                public void foo() {

                Then in Shared (probably in the c'tor) I'd expect there need to be a call like: ApplicationContext applicationContext = new FileSystemXmlApplicationContext("system/web/ape/WEB-INF/shared-springapp.xml") ???

                But perhaps you can set all that from the app's xml? With a Shared.setApplicationContext() ???