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-containe…)
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-…
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
devs(a)xwiki.org
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs