[xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
12 Apr
2008
12 Apr
'08
11:25 a.m.
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
12 Apr
12 Apr
12:02 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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
12:31 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
Hi Ruslan,
On Apr 12, 2008, at 12:02 PM, rssh wrote:
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent Massol
wrote
I don't understand what would not work... Would you mind giving some
details and use cases?
Thanks
-Vincent
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:01 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol wrote
Hi Ruslan,
On Apr 12, 2008, at 12:02 PM, rssh wrote:
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.
On Sat, 12 Apr 2008 11:25:29 +0200, Vincent
Massol wrote
I don't understand what would not work... Would you mind giving some
details and use cases?
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). Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
1:50 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
On Apr 12, 2008, at 1:01 PM, rssh wrote:
On Sat, 12 Apr 2008 12:31:12 +0200, Vincent Massol
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).
However even if we do we can use InheritableThreadLocal as pointed out
by Artem for example.
-Vincent
Hi Ruslan,
On Apr 12, 2008, at 12:02 PM, rssh wrote:
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. On Sat, 12 Apr 2008 11:25:29 +0200, Vincent
Massol wrote
I don't understand what would not work... Would you mind giving some
details and use cases?
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).
2:21 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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
4:16 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
On Apr 12, 2008, at 2:21 PM, rssh wrote:
good point! I think it should be ok since once a request is started on
a container instance, it continues on that same instance.
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]
)
Thanks
-Vincent
12:35 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:43 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <rssh(a)gradsoft.com.ua> 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
>
2:05 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <vincent(a)massol.net> 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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:18 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <vincent(a)massol.net> wrote:
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Apr
13 Apr
1:03 a.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
see below
On 4/12/08, Vincent Massol <vincent(a)massol.net> wrote:
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
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
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). 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 <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Pascal,
On Apr 12, 2008, at 12:35 PM, Pascal Voitot wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:09 a.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
On Apr 13, 2008, at 1:03 AM, Pascal Voitot wrote:
see below
On 4/12/08, Vincent Massol <vincent(a)massol.net> wrote:
XWikiContext (current) = request + response + session + app context
(new)
Thanks
-Vincent
On Apr 12, 2008, at 2:05 PM, Pascal Voitot wrote:
No no, I was speaking about context as XWikiContext or as Container
now... 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).
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <vincent(a)massol.net> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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 <rssh(a)gradsoft.com.ua> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Apr
12 Apr
4:43 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <vincent(a)massol.net> 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 <rssh(a)gradsoft.com.ua> 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).
12:58 p.m.
+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-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.
--
Artem Melentyev
13 Apr
13 Apr
11:13 a.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <vincent(a)massol.net> 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
--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo
1:34 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <kaaloo(a)gmail.com> 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 <vincent(a)massol.net>
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
--
Luis Arias
+33 6 14 20 87 93
skype : kaaloo
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:21 p.m.
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-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
4:33 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 <ludovic(a)xwiki.org> 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-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
8:34 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
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 
16 Apr
16 Apr
11:03 a.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
+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-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
11:15 a.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
+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 <jerome(a)xwiki.com> 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
--
Thomas Mortagne
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:51 p.m.
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.
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/
2:47 p.m.
New subject: [xwiki-devs] [VOTE] Using ThreadLocal vs passing the Context around for all method calls?
+1 for 2)
On Wed, Apr 16, 2008 at 1:51 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> 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
6000
days inactive
6004
days old
23 comments
10 participants
participants (10)
-
Artem Melentyev -
Jean-Vincent Drean -
Jerome Velociter -
Ludovic Dubost -
Luis Arias -
Pascal Voitot -
rssh -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol