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
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.
