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
