Re: WOLongResponsePage and locking/unlocking of editingContexts
Re: WOLongResponsePage and locking/unlocking of editingContexts
- Subject: Re: WOLongResponsePage and locking/unlocking of editingContexts
- From: Kaj Hejer <email@hidden>
- Date: Tue, 4 Nov 2003 22:53:00 +0100
At 12:49 -0500 03-11-03, email@hidden wrote:
I'd lock/unlock it in your actual worker method that's doing the work
with it, not in the WOComponent awake/sleep. The WOComponent is going to
be accessed multiple times (once for every refresh, naturally), while the
actual 'worker method' is still executing and doing it's work with the EC.
Of course, if you want the 'update' to get information from the EC (or
one of it's EO's)--you're going to have problems, becuase, of course, the
EC is locked from the worker thread, so can't be accessed from the
updating thread. But you just need a more complex design, where the
worker thread passes 'status' information through thread-safe methods to
be stored in a place where the 'update' thread can access. If you follow.
Hi!
Thank you for answering!
What this component do is to make a fetch (that take some time) in
performAction and then show the result of this fetch.
I solved this by let awake/sleep wait with the locking stuff until
performAction was finished, see the codefragents bellow:
public void awake() {
super.awake();
if (editingContext != null && isPerformActionFinished) {
editingContext.lock();
}
}
public void sleep() {
if (editingContext != null && isPerformActionFinished) {
editingContext.unlock();
}
super.sleep();
}
-Kaj :)
_______________________________________________
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.