I would avoid the create a new data context route. I played with that
some myself, but found that I wound up with weird application
behavior, mostly centering around objects not being in the same data
context.
Robert
On May 21, 2007, at 5/216:36 PM , Steve Wells wrote:
> Ok, I've raised *CAY-791* <https://issues.apache.org/cayenne/browse/
> CAY-791>
>
> That was my concern with InheritableTL, while I had some instant
> gratification that it worked I had worries about it that you have both
> expressed better than I.
>
> I changed my DataContext to not throw an exception and instead set
> a new
> DataContext, something like:
> public static DataContext getThreadDataContext() {//throws
> IllegalStateException {
> DataContext dc = (DataContext) threadDataContext.get();
> if (dc == null) {
> log.info("DataContext was null....getting a NEW
> datacontext...");
> DataContext dataContext = DataContext.createDataContext();
> threadDataContext.set(dataContext);
> //throw new IllegalStateException("Current thread has no
> bound
> DataContext.");
> }
>
> This now appears to be setting a new DataContext per session. By
> oddly
> enough the if condition is only true once during the entire server
> (Tomcat
> 6) runtime. Ie The first session to try and getThreadDataContext
> will have
> a dc == null, subsequent sessions are dc != null. Yes the
> WebApplicationContextFilter is still binding it but it gets "lost"
> that
> first time.
>
>
> I've investigated another option based on the ZK-Acegi integration
> work. ZK
> has a listener to copy the Acegi ThreadLocal context to the ZK event
> threads, this is described in the link above). On the Acegi side,
> acegi
> holds a SecurityContext in ThreadLocal, seemed to be a direct
> analog to a
> Cayenne DataContext. Of more interest to Cayenne directly would be
> the
> implementation of the strategies as you mentioned Andrus, such as a
> ThreadLocal, InheritableThreadLocal, Global and a HTTP Session
> strategy.
> These are in the org.acegisecurity.context package if this is
> interesting.
>
> Hope that helps and not hinders,
>
> Steve
>
>
>
>
>
> On 21/05/07, Tore Halset <halse..vv.ntnu.no > 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 - 22:30:43 EDT