cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Zeigler <robe...@puregumption.com>
Subject Re: Obtaining DataContext in ZK
Date Tue, 22 May 2007 02:29:56 GMT
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 <halset@pvv.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
>>
>>


Mime
View raw message