I currently use a modified version of ERChangeNotificationJMS that perform globalIDs exchange rather than snapshot. This globalIDs version is more stable on application load than the snapshot one. But I still get deadlock sometimes.
I've found the deadlock culprit: it's a call to the parent object store of a peer editing context. This is the code:
EOEditingContext editingContext;
editingContext = new EOEditingContext();
editingContext.lock();
try {
_invalidateObjectsWithGlobalIDs(editingContext, globalIDs);
} catch(Exception exception) {
NSLog.err.appendln(exception);
} finally {
editingContext.unlock();
} // finally
private static void _invalidateObjectsWithGlobalIDs(EOEditingContext editingContext, NSArray globalIDs) {
editingContext.lockObjectStore();
try {
editingContext.parentObjectStore().invalidateObjectsWithGlobalIDs(globalIDs);
} finally {
editingContext.unlockObjectStore();
} // finally
NSNotificationCenter.defaultCenter().postNotification(EOObjectStore.
InvalidatedAllObjectsInStoreNotification, editingContext, null);
} // _invalidateObjectsWithGlobalIDs
On application load, I get deadlocks on "_invalidateObjectsWithGlobalIDs(editingContext, globalIDs)" line. Unfortunately, I couldn't get the stack trace of the thread: A "kill -3 <pid>" is not enought, I must perform a "kill -9 <pid>" to stop the application.
So, here is my question: is there a safer way to invalidate globalIDs rather than using "editingContext.parentObjectStore().invalidateObjectsWithGlobalIDs(globalIDs);" with properly locked context and object store? Any hints or ideas to avoid these deadlocks?
Kind regards,
--
<x-tad-bigger>Francis Labrie</x-tad-bigger>
Saint-Bruno-de-Montarville, Quebec, Canada
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
