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

  • CGLIB Factory performance

    Hi Folks -
    I'm trying to squeeze our app for performance. We have a complex application where there may be up to 25 calls in the app layer to properly render the view. Each call to the app layer hits a spring-manged controller, instantiated as a prototype.

    I would like to retrieve each prototype instance as efficiently as possible. Requesting the instances from the spring context performs a significant amount of house keeping duties to determine advisors and target source etc at runtime, and ultimately return a new instance of a CGLIB generated class.

    Since I know that the interceptor and target configuration does not change, is there any way to short circuit the work performed in AbstractAutoProxyCreator.postProcessAfterInitializ ation()?

    For example, I have isolated access to the application context in our application, and if I cache the CGLIB advised instance of a bean retrieved from spring, I can use it as a factory for subsequent instances. Doing this greatly improves performance, given that we may need to create several advised beans in a single page view.

    I would prefer, however, that the logic for using the factory versus creating a fresh instance could be left up to the spring context, instead of adding this logic on top of the spring context.

    Any thoughts on this? Any reason I should NOT be caching a bean instance for use as a CGLIB factory?


  • #2
    did you consider making the spring-manged controller thread safe and configure it as a singleton?


    • #3
      Yes I considered this, since this would avoid the situation altogether, but the controllers require some context information. This could be passed in various other ways (threadlocal etc), but all of those ways are much more intrusive than simply making the controller, actually a business delegate, stateful and contain its own context.



      • #4
        I would recommend investing in making the controller thread safe and storing teh context inside the ThreadLocal. However here are some resources related to caching:


        • #5
          This is going off on a slight tangent, but I'd profile an app first before I tried to tune it.

          We've used JProbe on pretty much every project over the last 5-6 years and I find I can never guess where an app is spending it's time. I also always find places where I would have never guessed the app was wasting time.

          If you're not using a profiling tool, this might help your tuning efforts. You'll also be able to quantify any improvements you make which is always a good thing.