I don't really like the ThreadLocal because it seems too much "nice" to be true and I wonder what is the problem :) But, after some studying, it seems ThreadLocal might be the only clever solution in Java for propagating the container without passing it to all functions. Apparently, speaking performace, ThreadLocal seems to be ok. The only thing to take care about is cleaning the ThreadLocal to prevent memory leaks... Naturally, it implies the strong association between unit of work and thread but as Vincent said, today, there is not many usecases where a unit of work could need to be multi-threaded. The only case I can see is the case when a component would need to call other components which run in other threads because they perform heavy or asynchronous operations. For example, imagine you call an external indexing engine or a distributed component. And even in this case, I wonder if there is a problem with ThreadLocal. In fact, the only important thing a component requires is the injection of the container at the right time and in the right scope... and also a safe getter... Using ThreadLocal, it would be something like (without taking into account previous context storing/restoring, reduction of lookups and memory leaks) Component.setContainer(Container c) { threadLocal.set(c); } and Container Component.getContainer() { return threadLocal.get(); } Using the Servlet model, interceptors might be a simple way to inject the right container in the component... I think ThreadLocal will solve 80-90% of our usecases and for the remaining cases, we will use the plain old Container passed using the injection or even as a function parameter to the component... So I VOTE +1 if you keep code as independent as possible from ThreadLocal using some kind of ContainerInjector from which Component would inherit... Regards Pascal On 4/13/08, Ludovic Dubost <[email protected]> wrote:
I'm not a huge fan of fully absolute variables but as long as we can guarantee that we have always access to ThreadLocal, I'm fine since it's a bad idea anyway to share a context from one thread to another (we need a generic method to clean it up when we do like in the Lucene or Scheduler plugins).
Now does every case allow ThreadLocal ? Do clustering solutions like TeraCotta allow it ?
I would prefer if we kept all request specific in one context object (request, response, etc..)
Ludovic
Vincent Massol wrote:
Hi,
In the new xwiki architecture we need to take a call for passing the request, response and session around (what is currently called the XWikiContext). We have 2 solutions: 1) we pass it around for all method calls as it's currently done 2) we use ThreadLocal(s). If you don't know what it is see for ex: http://crazybob.org/2006/07/hard-core-java-threadlocal.html .
The advantage of solution 2) is that any component in the new architecture can decide to have the Container component injected (see http://svn.xwiki.org/svnroot/xwiki/xwiki-platform/core/trunk/xwiki-container... ) and thus be allowed to access the request, response and session objects without having all its method add a Container object passed to it.
The downside of solution 2) is simply that we associate Unit Of Work with Threads. But since we use a Servlet model and since I don't see any foreseeable future where we would want to use several threads for the same unit of work, I don't think this is limitating for us. See http://blog.objectmentor.com/articles/2007/09/04/thread-local-a-convenient-a... for some explanation on this.
So right now and even though ThreadLocal sound a little bit "hackish", I think this is still my preference as it'll save us from having to pass Container objects everywhere.
Since this is an important architecture decision I wanted to have a vote for it.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs