Re: WOLongResponsePage and locking/unlocking of editingContexts
Re: WOLongResponsePage and locking/unlocking of editingContexts
- Subject: Re: WOLongResponsePage and locking/unlocking of editingContexts
- From: email@hidden
- Date: Mon, 03 Nov 2003 12:49:51 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
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.
--Jonathan
On Mon, 3 Nov 2003 18:16:42 +0100 Kaj Hejer wrote:
> Hi!
>
> We have now begun to lock/unlock all our editingContexts in
> awake/sleep in Session. This seems to work just fine more most cases.
>
> but... (isn't there always one but ;-) in one component extending
> WOLongResponsePage we create an editingContext in the constructor with
>
> editingContext = new EOEditingContext(new EOObjectStoreCoordinator());
>
> to not block the database for the rest of the sessions. Since Session
> don't know about this editingContext we lock/unlock it in awake/sleep
> in this compoent.
>
> To see if we have any locking issues we added the following code to
> our app
>
> NSLog.setAllowedDebugLevel(NSLog.DebugLevelInformational);
> NSLog.allowDebugLoggingForGroups(NSLog.DebugGroupMultithreading);
> setAllowsConcurrentRequestHandling(true);
>
> we got the following warning in our performAction method
>
> *** EOEditingContext: access when another thread holds a lock:
> _eoForGID()!
>
> since the editingContext was locked in awake.
>
> Then we tried to add ec.lock() in the start of the performAction and
> ec.unlock() at the end of the performAction (in addition to the
> lock/unlock in awake/sleep).
>
> When using a "normal" EOEditingContext we don't get any warnings but
> when we use a LockErrorScreamerEditingContext (<url:
> ttp://wodev.spearway.com/cgi-bin/WebObjects/WODev.woa/wa/Main?wikiPage=Track
> ingEditingContextLocks>) we get
>
> !!! Attempting to lock editing context from Thread-4 that was
> previously locked in WorkerThread0
>
>
> What is the best strategy for locking/unlocking an editingContext in
> a WOLongResponsePage?
>
>
> btw:
> Thank you to Jonathan 'Wolf' Rentzsch for
> LockErrorScreamerEditingContext! It has revealed the source of some
> of our locking issues! :)
>
>
> -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.
_______________________________________________
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.