From dev-return-91972-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Jan 03 15:37:52 2007 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 51956 invoked from network); 3 Jan 2007 15:37:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Jan 2007 15:37:48 -0000 Received: (qmail 57520 invoked by uid 500); 3 Jan 2007 15:37:48 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 57465 invoked by uid 500); 3 Jan 2007 15:37:48 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 57445 invoked by uid 99); 3 Jan 2007 15:37:48 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jan 2007 07:37:48 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [130.237.222.115] (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jan 2007 07:37:37 -0800 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [192.168.105.137] ([62.84.203.102]) (authenticated bits=0) by smtp.nada.kth.se (8.12.11.20060308/8.12.11) with ESMTP id l03FbFcw016720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Jan 2007 16:37:16 +0100 (MET) Message-ID: <459BCDA6.9000203@nada.kth.se> Date: Wed, 03 Jan 2007 16:37:10 +0100 From: Daniel Fagerstrom User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Object pooling considered harmful References: <459AD722.6090304@nada.kth.se> <459AE2C3.5030802@gmx.de> In-Reply-To: <459AE2C3.5030802@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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: 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