cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Object pooling considered harmful
Date Wed, 03 Jan 2007 15:37:10 GMT
Joerg Heinicke skrev:
> On 02.01.2007 23:05, Daniel Fagerstrom wrote:
>> One complication in our work in making the Cocoon components work in 
>> a standard Spring container without special Avalon support is that a 
>> large amount of our components are Poolable (or more specifically 
>> Recyclable). And Spring doesn't have any concept of object pooling.
>>
>> Even worse Spring doesn't even have a concept of returning components 
>> to the container. For singletons the container can call a destroy 
>> method when the component goes out of scope. But for non singletons 
>> (prototypes) your are on your own and have to take care of destroying 
>> the component yourself. Of course it is possible to implement pooling 
>> for Spring anyway, but Spring doesn't help us.
>
> Not that I want to propagate pooling, but Spring at least provides 
> some support:
> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/aop/target/CommonsPoolTargetSource.html

>
> http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/beans/factory/config/Scope.html

>
>
> I don't know anything about the CommonsPoolTargetSource,
I get the impression that it is used internally in the AOP framework, 
but I don't know either.

> but the Scope obviously provides a destruction callback mechanism.
Only for singletons though. But it is usable for setting up a bean 
factory that in turn manage poolables. My first thought was to implement 
some mechanism so that you could make POJOs poolable in a non intrusive 
way in Spring:

  <bean id="mybean" class="MyClass" scope="request">
    <poolable:pool recycle-method="recycle" pool-size="64"/>
  </bean>

or something like that. But then I learned what I described in the mail 
and abandoned the project.
> You only need to know the end of the scope, what's easy for request or 
> session. Don't know what other scopes might apply.
A sitemap scope could be useful for simplifying the component handling 
in sub sitemaps. For poolables, request and session scope should be 
enough, AFAICS.

/Daniel


Mime
View raw message