Re: Obtaining DataContext in ZK

From: Steve Wells (websystem..mail.com)
Date: Mon May 21 2007 - 23:22:51 EDT

  • Next message: Dirk Olmes: "Re: [JIRA] Created: (CAY-790) commitChanges() doesn't imply commit in db ?"

    Hi Robert,

    So were you hacking out a similar approach to solve my issue? Were you not
    always getting the correct DC from the sessions?

    My approach would be to have a simple per session DC and a global web app
    one...at this stage, hardly seems dangerous, what could possibly go wrong?
    ;)

    On 22/05/07, Robert Zeigler <robert..uregumption.com> wrote:
    >
    > 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 - 23:23:29 EDT