Ok, let's start thinking about some "new" things :) (Actually this is not new but who cares?)
a) Proxy Handling in Fortress Currently it's possible to define/configure if/how Fortress is creating a proxy for a component. I'm wondering if this flexibility is really required. I think we should always create a proxy. There are imho three reasons: - security: if you create a proxy, the client can't cast the component to the implementation class. - Performance/remove a bottle neck: currently without a proxy all components are stored on lookup in a big hash map together with their handler and on release the handler is taken out the map to properly release the component. So this map is a bottle neck for multi-threaded apps. With a proxy we can store the handler in the proxy and remove this bottle neck. Actually this is already implemented in Fortress if you use proxies :) - Better Support for non thread-safe components. See below. Now, by always creating a proxy we can remove/clean up some code in Fortress and it gets a little bit smaller as well :) WDYT? b) Pooling (or handling of non thread-safe components) A problem that always bites me is that you have to know if a component is thread safe or not. For example, if you have a thread safe component that uses other components, then you can't simply lookup this component in service()/compose(). You can only safely do this, if the component implementation you look up is thread safe as well. If it is pooled or single threaded you have to lookup/release this component each time you use it. So, if you really want to develop a multi-threaded app, you either have to know which components are thread safe or not or you have to lookup release a component each time you use it. I think both solutions are not very nice :) Now, there have been a lot of discussions about this topic. For example, we had suggestions that all components should be thread safe. Even if this would be an option for the future, it's just this: "the future". We currently have a lot of apps out there that use pooled and single threaded components. Similar is the discussion about pooling components yourself or let the JVM pool them for you. This way or that way: the components are pooled but not thread safe. So, a rather long introduction for the problem :) Now, I think one solution for this is to say "let's pretend that all components are thread safe". So, the basic idea is to create a proxy for each component that ensures that the use of the underlying component is in a thread safe way (and this is the third reason for proxies). For example, if you're using a pooled component, you get a proxy that during one request, fetches a component from a pool - if the component is used - and releases the component when the request is finished. Therefore you need to notify the container when a request starts and finishs. During the request the pooled components are stored somewhere (thread local for example) and when the request is finished they are released. This mechanism is only required for pooled or single threaded components, thread safe components don't need this extra behaviour. This would allow the client to lookup a component in service() and just use it and the underlying logic takes care that you don't get threading problems. I conclude from the docs, that e.g. HiveMind is doing it this way. WDYT? Carsten Carsten Ziegeler Open Source Group, S&N AG http://www.osoco.net/weblogs/rael/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
