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-containers/) >> 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-abomination >> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
