Re: WOLongResponsePage and EOF task
Re: WOLongResponsePage and EOF task
- Subject: Re: WOLongResponsePage and EOF task
- From: Christian Pekeler <email@hidden>
- Date: Tue, 23 Mar 2004 13:18:49 -0700
The problem with using a WOLongResponse page with an EOF task that
uses the session().defaultEditingContext(), is that if the long
running task keeps the session().defaultEditingContext() locked, then
the WOLongResponse page can't get in to check it's status.
I'm also still looking for a clean solution to this problem. I usually
work around this problem by not binding subcomponents in the
WOLongResponse page to EOs. Instead, I bind them to simple value-ivars
which get updated by the lock-owning background thread. I consider this
a workaround until I figure out a cleaner solution.
What if, in my long running task which is doing a variety of
statements involving EOF, I just periodically call:
session().defaultEditingContext().unlock();
session().defaultEditingContext().lock();
Just like that. To give the WOLongResponse page a chance to get in and
do it's stuff, if it's waiting.
Is this a good idea?
Doesn't look very clean to me, either.
Another question: I've _never_ been able to get the "access to EOF
object without lock" warning to actually appear in my log. Can anyone
supply a formula for turning on this type of logging, that is actually
demonstrated to work for them, in OSX WO 5.2? (5.2.1, I'm afraid, but
I don't think anything relevant probably changed from .1 to .3)
EOObjectStore._resetAssertLock();
NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupRequestHandling +
NSLog.DebugGroupMultithreading + NSLog.DebugGroupEnterpriseObjects);
NSLog.debug.setAllowedDebugLevel(NSLog.DebugLevelInformational);
Christian
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.