Re: WOLongResponsePage and locking/unlocking of editingContexts
Re: WOLongResponsePage and locking/unlocking of editingContexts
- Subject: Re: WOLongResponsePage and locking/unlocking of editingContexts
- From: Chuck Hill <email@hidden>
- Date: Tue, 04 Nov 2003 10:21:06 -0800
- Organization: Global Village Consulting, Inc.
Hi Kaj,
I don't know if the warning
> !!! Attempting to lock editing context from Thread-4 that was
> previously locked in WorkerThread0
is all that bad or unexpected when using the LRP. WO serializes
access to sessions so in the general case this indicates that an ec
was left locked after the Request-Response loop ended. That means
that your program just deadlocked.
When using the LRP and sharing an ec between a page (access serialized
by the session) and the long running process, I would expect to see
one or the other block temporarily like that. This should not result
in deadlock, but will probably prevent the LRP page from working as
expected.
The best thing to so is to have the process create, lock, unlock, and
dispose of its own editing context.
Chuck
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.
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
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.