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
