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? 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. Carsten
