[xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures). -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
Hi Ruslan, On Apr 12, 2008, at 12:02 PM, rssh wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
I don't understand what would not work... Would you mind giving some details and use cases? Thanks -Vincent
On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote
Hi Ruslan,
On Apr 12, 2008, at 12:02 PM, rssh wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
I don't understand what would not work... Would you mind giving some details and use cases?
For example - write something like 'doParallel' from http://www.jroller.com/melix/entry/simplifiying_java_util_concurrent_with It is common to call long external process in one branch (for example fetching external URL) and check for timeout in other branch. All closures, which would evaluated inside doParallel will have not access to ThreadLocal.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
On Apr 12, 2008, at 1:01 PM, rssh wrote:
On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote
Hi Ruslan,
On Apr 12, 2008, at 12:02 PM, rssh wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
I don't understand what would not work... Would you mind giving some details and use cases?
For example - write something like 'doParallel' from http://www.jroller.com/melix/entry/simplifiying_java_util_concurrent_with
It is common to call long external process in one branch (for example fetching external URL) and check for timeout in other branch.
All closures, which would evaluated inside doParallel will have not access to ThreadLocal.
I don't think we should allow user code in document pages the ability to create threads. This is going to be asking for trouble IMO (Remember that inside a J2EE container you're not allowed to manipulate threads). However even if we do we can use InheritableThreadLocal as pointed out by Artem for example. -Vincent
I don't think we should allow user code in document pages the ability to create threads. This is going to be asking for trouble IMO (Remember that inside a J2EE container you're not allowed to manipulate threads).
Hmm -- I was think about case lightweight Apache/Tomcat. If we think about J2EE - yes, it's not allowed, but is using ThreadLocal is allowed inside J2EE application ? (And yet one moment to care is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 [workaround is cleaning ThreadLocal at the end of each request] ) -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
On Apr 12, 2008, at 2:21 PM, rssh wrote:
I don't think we should allow user code in document pages the ability to create threads. This is going to be asking for trouble IMO (Remember that inside a J2EE container you're not allowed to manipulate threads).
Hmm -- I was think about case lightweight Apache/Tomcat.
If we think about J2EE - yes, it's not allowed, but is using ThreadLocal is allowed inside J2EE application ?
good point! I think it should be ok since once a request is started on a container instance, it continues on that same instance.
(And yet one moment to care is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6254531 [workaround is cleaning ThreadLocal at the end of each request] )
Thanks -Vincent
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way... ThreadLocal and stateless approach may be compliant but I'm sure about this :) Pascal On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Pascal, On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet). The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module. To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object. Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
After looking at the code, I see what you mean and the model seems quite generic and on the good way! Excuse me for my stupid ideas... wouldn't it be possible to do the same for the context? The idea is not to be forced to pass it to every call... Could it be possible to create an abstract and generic mechanism that passes context and one implementation would be ThreadLocal... And if later, we discover a strong problem, we could have another implementation... regards Pascal On 4/12/08, Vincent Massol <[email protected]> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object.
Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
After looking at the code, I see what you mean and the model seems quite generic and on the good way!
Excuse me for my stupid ideas... wouldn't it be possible to do the same for the context?
You mean application context? If so then it doesn't mean anything since the application context is the same for the whole duration of the application. The ThreadLocal is only required for request/response and session since those are different per user (thus per thread). -Vincent
The idea is not to be forced to pass it to every call... Could it be possible to create an abstract and generic mechanism that passes context and one implementation would be ThreadLocal... And if later, we discover a strong problem, we could have another implementation...
regards Pascal
On 4/12/08, Vincent Massol <[email protected]> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object.
Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
see below On 4/12/08, Vincent Massol <[email protected]> wrote:
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
After looking at the code, I see what you mean and the model seems quite generic and on the good way!
Excuse me for my stupid ideas... wouldn't it be possible to do the same for the context?
You mean application context? If so then it doesn't mean anything since the application context is the same for the whole duration of the application. The ThreadLocal is only required for request/response and session since those are different per user (thus per thread).
No no, I was speaking about context as XWikiContext or as Container now... As you say , for AppContext, it means nothing... I was also speaking about an abstract design to inject the container in components without be forced to pass it to all functions... ThreadLocal would be an implementation of this "container injector" but as it might have counter effects that we don't see today, we should keep the abstraction so that we can replace it if we find something else... I'm going to study a bit and think about all of this :) regards Pascal -Vincent
The idea is not to be forced to pass it to every call... Could it be possible to create an abstract and generic mechanism that passes context and one implementation would be ThreadLocal... And if later, we discover a strong problem, we could have another implementation...
regards Pascal
On 4/12/08, Vincent Massol <[email protected]> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object.
Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 13, 2008, at 1:03 AM, Pascal Voitot wrote:
see below
On 4/12/08, Vincent Massol <[email protected]> wrote:
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
After looking at the code, I see what you mean and the model seems quite generic and on the good way!
Excuse me for my stupid ideas... wouldn't it be possible to do the same for the context?
You mean application context? If so then it doesn't mean anything since the application context is the same for the whole duration of the application. The ThreadLocal is only required for request/ response and session since those are different per user (thus per thread).
No no, I was speaking about context as XWikiContext or as Container now...
XWikiContext (current) = request + response + session + app context (new) Thanks -Vincent
As you say , for AppContext, it means nothing... I was also speaking about an abstract design to inject the container in components without be forced to pass it to all functions... ThreadLocal would be an implementation of this "container injector" but as it might have counter effects that we don't see today, we should keep the abstraction so that we can replace it if we find something else... I'm going to study a bit and think about all of this :)
regards Pascal
-Vincent
The idea is not to be forced to pass it to every call... Could it be possible to create an abstract and generic mechanism that passes context and one implementation would be ThreadLocal... And if later, we discover a strong problem, we could have another implementation...
regards Pascal
On 4/12/08, Vincent Massol <[email protected]> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object.
Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote > Hi, >
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
After looking at the code, I see what you mean and the model seems quite generic and on the good way!
The only problem is that I haven't found a way to inject the correct implementation of Container in the components that need it. Thus for now the only solution I have is by passing it to every method.... It's the calling code that knows which implementation to pass... Any idea? Thanks -Vincent
Excuse me for my stupid ideas... wouldn't it be possible to do the same for the context? The idea is not to be forced to pass it to every call... Could it be possible to create an abstract and generic mechanism that passes context and one implementation would be ThreadLocal... And if later, we discover a strong problem, we could have another implementation...
regards Pascal
On 4/12/08, Vincent Massol <[email protected]> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
Even if I can't say I'm an expert of XWiki yet, let me give my point of view... The ThreadLocal is interesting but can bring lots of design constraints also... Moreover, I think the stateless approach would be an insurance for future evolutions and passing the context seems better for that... For example, I have been thinking about an XWiki engine using service oriented approach... without the Servlet model... A raw XWiki service provider without knowledge of its communication and presentation layers... Like this, it would be easy to imagine P2P, balancing, grid computing etc... To my mind, the component model goes in this way...
Actually we're not bound to the Servlet model at all. If you check the container component in SNV you'll see that it's made to be generic with a first implementation for Servlet (in component-servlet).
The only constraint is that whatever your development model you must provide an implementation of the Container API, i.e. implement the notion of request, response, session and application context. This is what we'll do for example in the scheduler or XMLRPC module.
To be honest, I still need to finish this container component since I don't fully know yet how the correct implementation can be passed to the component needing the Container object.
Thanks -Vincent
ThreadLocal and stateless approach may be compliant but I'm sure about this :)
Pascal
On 4/12/08, rssh <[email protected]> wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol wrote
Hi,
Sorry, may be this is not my question, but: I can imagine situation, where ThreadLocal approach will fail: it's when we do asynchronics call to some external entity with callback. In such case callback will not receive context in ThreadLocal. And it is possible (and very common approach) to do this from groovy scripts (as groovy has closures).
+1 to 2). It is very awkward to pass context in Every method. We can use InheritableThreadLocal to provide the context in child threads if needed. 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.
-- Artem Melentyev
Hi Vincent, I recently had an issue with 2 in the following context: - the framework, in this case exo, expects the container in ThreadLocal - the component we wished to integrate (a webapp) relied upon its own thread management for some lower level processing part of which needs to call the exo platform through an adapter We initially did not know that the framework depended on this, but after some exchanges with the exo team we tried the approach they use in their exo applications which is to setup the ThreadLocal with a servlet filter. This did not work because of course the adapter thread did not have its ThreadLocal setup. We finally ended up putting the setup code in the adapter thread, because in this case it was the only point of interaction with exo, but there could have been other points of interaction, and so its not a general solution. So in conclusion, my experience is that the technique really needs to be well documented, especially if wiki level scripting or plugins may need this type of callback behavior to the xwiki framework through other frameworks that manage their own threads. P.S. Didn't know about InheritedThreadLocal, sounds cool. Luis On Sat, Apr 12, 2008 at 11:25 AM, Vincent Massol <[email protected]> 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
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo
Vincent, I have a question: do you have idea of who, when and how the right container will be injected as a ThreadLocal? (was it your question "Any idea?"some mails ago?) I'm drawing some parallel with the hibernate session-per-request model which is easily implemented with ThreadLocal... About InheritableThreadLocal, I found this: "ThreadLocal's less thread-safe cousin, InheritableThreadLocal The ThreadLocal class has a relative, InheritableThreadLocal, which functions in a similar manner, but is suitable for an entirely different sort of application. When a thread is created, if it holds values for any InheritableThreadLocal objects, these values are automatically passed on to the child process as well. If a child process calls get() on an InheritableThreadLocal, it sees the same object as the parent would. To preserve thread-safety, you should use InheritableThreadLocal only for immutable objects (objects whose state will not ever be changed once created), because the object is shared between multiple threads. InheritableThreadLocal is useful for passing data from a parent thread to a child thread, such as a user id, or a transaction id, but not for stateful objects like JDBC Connections." regards Pascal On 4/13/08, Luis Arias <[email protected]> wrote:
Hi Vincent,
I recently had an issue with 2 in the following context:
- the framework, in this case exo, expects the container in ThreadLocal - the component we wished to integrate (a webapp) relied upon its own thread management for some lower level processing part of which needs to call the exo platform through an adapter
We initially did not know that the framework depended on this, but after some exchanges with the exo team we tried the approach they use in their exo applications which is to setup the ThreadLocal with a servlet filter. This did not work because of course the adapter thread did not have its ThreadLocal setup. We finally ended up putting the setup code in the adapter thread, because in this case it was the only point of interaction with exo, but there could have been other points of interaction, and so its not a general solution.
So in conclusion, my experience is that the technique really needs to be well documented, especially if wiki level scripting or plugins may need this type of callback behavior to the xwiki framework through other frameworks that manage their own threads.
P.S. Didn't know about InheritedThreadLocal, sounds cool.
Luis
On Sat, Apr 12, 2008 at 11:25 AM, Vincent Massol <[email protected]> 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
-- Luis Arias +33 6 14 20 87 93 skype : kaaloo _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
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
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
+0 for 2), as I do not fully get the implications/possible issues of using ThreadLocal, but also do not like the current way of passing context to method calls. Regards, Jerome
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
+1 for 2) as I really don't like the context bag given to all methods and I don't see a real blocker use case (even I'm sure I did not think of all use cases). On Wed, Apr 16, 2008 at 11:03 AM, Jerome Velociter <[email protected]> wrote:
+0 for 2), as I do not fully get the implications/possible issues of using ThreadLocal, but also do not like the current way of passing context to method calls.
Regards, Jerome
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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.
After reading all the comments on this topic, I agree that we should use ThreadLocal (inheritable) objects. The biggest problem seems to be what to do with background tasks. Well, the problem would be that the context is not up-to-date, and some context objects are missing, but that is also true if we pass the XWikiContext around. We should document that starting asynchronous/background threads might lose the context, so the code should not rely on always having the full context there. We should also have a way to retrieve request-independent up2date component instances (like storage, data model, notification manager...). -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 for 2) On Wed, Apr 16, 2008 at 1:51 PM, Sergiu Dumitriu <[email protected]> wrote:
The biggest problem seems to be what to do with background tasks. Well, the problem would be that the context is not up-to-date, and some context objects are missing, but that is also true if we pass the XWikiContext around.
Yes, a good example of this is the scheduler which keeps the outdated and incomplete context he got at startup. -- Jean-Vincent Drean
participants (10)
-
Artem Melentyev -
Jean-Vincent Drean -
Jerome Velociter -
Ludovic Dubost -
Luis Arias -
Pascal Voitot -
rssh -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol