Announcement Announcement Module
No announcement yet.
Forcing singletons re-creation by the container Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Forcing singletons re-creation by the container

    Hi, all.

    I have a question about forcing re-creating singletons by the IoC container vs custom scopes, but I think I'll have to expose the whole scenario before asking. I'll try to make it as simple as possible.

    My ServiceClass is managed by the IoC container (created by Spring IoC), and its constructor receives as parameters values from a database, retrieved by IoC container using Apache Commons Configuration:

      <bean id="serviceClass" class="package.ServiceClassImpl">
         <!-- dataSourceEndpoint is a org.apache.commons.configuration.DatabaseConfiguration
                that will retrieve the endpoint from database -->
         <constructor-arg ref="dataSourceEndpoint" />
    ServiceClass will then create StubClass in its construction, and set the stub's endpoint to the value retrieved by dataSourceEndpoint. ServiceClassImpl is an autowired attribute of a general application's business class, and this business class is autowired to the web apps controller:

    Controller (has an autowired attribute) ->
    ___Autowired Business Class (has an autowired attribute) ->
    ______ServiceClassImpl (has an attribute created on its constructor) ->

    The problem is, as using default bean scope (singleton) Spring will create a single instance of ServiceClass, and this will never be created again, if I need to change the endpoint I'll have to update the database and then restart the entire application so this can read the new value, while the desired behaviour was having this value read again after some time (eg.: a couple of hours).

    I don't know whether I misunderstood the scope's concept, but it looks like I can create a new scope for my beans, and handle on the scope implementation the timeouts. On my custom scope implementation I could check whether a bean was created a before my timeout period, and create a new one when it has expired.

    And all of my beans (from controller to ServiceClassImpl) should use this new scope, so I can guarantee the ServiceClassImpl will be re-created (if I don't change all beans' scope I could have an old ServiceClassImpl attached to the business class).

    Am I right? Is that the way to go?
    Last edited by rcotta; Dec 31st, 2011, 11:28 AM. Reason: formatting

  • #2
    I would have avoided this problem by not having database-read data be autowired. Read the database through a DAO on a schedule or from a trigger, and store that data into the bean that uses it.


    • #3
      Hmmm... we may even forget the auto-wired stuff. Now I can see it's not the most relevant point on my problem of needing to have data reloaded.

      It would be the same if I had the entire Controller -> BusinessClass -> ServiceImpl defined on the Spring's XMLs used to instantiate the beans. I would continue having one singleton BusinessClass, one singleton ServiceImpl attached to this BusinessClass and in consequence a Stub that will never be recreated.

      The beans (about 50 beans that accesses 50 different web services) are used on several (30 or more) JSR286 portlets, so I don't know whether there's a good way to implement a scheduler or a trigger to refresh this data.

      I was wondering about the custom context because I would need to a) change the XMLs that instantiate the beans and b) implement very carefully my custom context (so this have good performance and don't leak memory), without the need to change plenty of code.

      Thanks a lot for your attention!