Tore,
Of course you are absolutely right about thread-safety. And there are
various strategies to setup a context for multi-threaded use (peer
DataContext, nested DataContext, etc). The question is do we stick
with a single default strategy (session context) and leave the rest
for users to figure out, or we add a few more strategies to Cayenne
framework proper. If we go with the former, it is logical to use
InheritableThreadLocal in DataContext. If we go with the later, we
need to discuss possible strategies and implement corresponding filters.
In fact since we are moving from DataContext to a more generic
ObjectContext interface, DataContext.getThreadDataContext () is a
wrong place to keep your context. So we'll need to address this
design rather sooner than later.
Andrus
On May 21, 2007, at 11:21 AM, Tore Halset wrote:
> Hello.
>
> I do not think InheritableThreadLocal is a good place to put your
> DataContext as a DataContext should only be used by a single thread
> at a time. You may experience random hard-to-debug problems if you
> use the same DataContext for different (child) threads.
>
> This problem is also somewhat relevant for the cayenne
> WebApplicationContextFilter as it bounds a DC to the users session
> and a session can have multiple parallell requests. I am currently
> moving over to a variant of the click filter that allows for a
> single DC per thread and checks that there are no uncomitted
> objects in the context at the end of each request-response loop.
>
> Perhaps ZK has some place where you can initiate the ZK-threads
> DataContext?
>
> Regards,
> - Tore.
>
> On May 21, 2007, at 06:23, Steve Wells wrote:
>
>> Hi,
>>
>> I've been playing with the ZK (www.zkoss.org) framework for
>> building AJAX
>> apps, and so far have found it rather impressive and easy to use.
>>
>> Having hit my first roadblock now is getting DataContext, as each
>> ZK request
>> runs in a separate thread (see:
>> http://www.zkoss.org/smalltalks/zkacegi/zkacegi.dsp
>> ) I think this is the problem why I can't get DC
>> with WebApplicationContextFilter and
>> DataContext.getThreadDataContext (). I
>> get "IllegalStateException: Current thread has no bound
>> DataContext."
>>
>> Looking into src for DataContext I see this comment // TODO: Andrus,
>> 11/7/2005 - should we use InheritableThreadLocal instead?
>>
>> So I subclassed DataContext and overrode the :
>> ThreadLocal threadDataContext
>>
>> to be
>>
>> InheritableThreadLocal threadDataContext
>>
>> changed WebApplicationContextFilter to call my subclassed
>> DataContext and
>> bingo it works.
>>
>> Not sure if anyone else has run into this kind of thing before? I
>> would
>> raise a JIRA issue but I'm not yet confident that this is the 100%
>> correct
>> solution.
>>
>> Steve
>
>
This archive was generated by hypermail 2.0.0 : Mon May 21 2007 - 04:44:34 EDT