Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EDB3B3B.9020706@verizon.net>
Date: Mon, 02 Jun 2003 07:55:39 -0400
From: Vadim Gritsenko <vadim.gritsenko@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3) Gecko/20030312
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: FragmentExtractor getting and releasing Store every time?
References: <LKENJPKDAIKAPKHEOCMMKEIJDMAA.cziegeler@s-und-n.de>
In-Reply-To: <LKENJPKDAIKAPKHEOCMMKEIJDMAA.cziegeler@s-und-n.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:

>Torsten Knodt wrote:
>  
>
>>On Sunday 01 June 2003 15:51, Carsten Ziegeler wrote:
>>CZ> The safest way is to lookup/release a component every time you
>>CZ> need it, so the fragmentextractor uses the "correct" approach.
>>CZ> If you know that the component you want to use is ThreadSafe
>>CZ> and will always be ThreadSafe than you can optimize your code
>>CZ> and lookup the component only once - this optimization has been
>>CZ> done in the xslttransformer.
>>XSLTProcessorImpl uses Store.TRANSIENT_STORE, like the
>>FragmentExtractor. I
>>haven't mentioned this explicitly.
>>I have looked into the interfaces, and when I understand right, I
>>had to look,
>>if store implements ThreadSafe. Store doesn't implement
>>ThreadSafe, but the
>>MRUMemoryStore, which is used as default in cocoon. So I'd say
>>it's a bug in
>>XSLTProcessorImpl. Agreed? 
>>

No.


>>What I would do, is asking in avalon-users for
>>changing XSLTProcessorImpl and perhaps others or to have Store implement
>>ThreadSafe. But I guess, Store is already released.
>>    
>>
>
>We have to distinguish between the component (it's interface) and the
>implementation. The interface should never expose details about the
>implementation, so an implementation detail like ThreadSafe etc. is
>not part of the interface which in this case is Store.
>
>However, the implementation "decides" if it is thread safe, poolable
>or whatever.
>
>Now, the optimization I was refering to can only take place *if* you
>know which implementation for a component is really used and *if*
>this specific implementation is ThreadSafe. This is a dangerous
>assumption! If you assume a component is implemented in a thread safe
>manner and this changes sometime and you don't reflect these changes
>than you will quickly result in threading problems.
>

Not in this case though. I think you forgot that XSLTProcessor is 
Recyclable, and not ThreadSafe.

Vadim