On Apr 13, 2008, at 2:21 PM, Ludovic Dubost wrote:
I'm not a huge fan of fully absolute variables
neither am I. I'm still not 100% sure ThreadLocal is the best solution...
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 don't see the problem with clustering solutions since the ThreadLocal would be set when the request enters the servlet container and removed when the response is sent. Since a request is going to be handled by the same servlet container instance for the duration of the request, I don't see how it could go wrong.
I would prefer if we kept all request specific in one context object (request, response, etc..)
Not sure what you mean. Right now in the new container component I have one object called Container which holds: application context, request, response and session. Thanks -Vincent
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