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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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 >> >>
