Deadlock using EOObjectStore.invalidateObjectsWithGlobalIDs(NSArray)
Deadlock using EOObjectStore.invalidateObjectsWithGlobalIDs(NSArray)
- Subject: Deadlock using EOObjectStore.invalidateObjectsWithGlobalIDs(NSArray)
- From: Francis Labrie <email@hidden>
- Date: Wed, 20 Sep 2006 12:15:57 -0400
Hi,
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden