Hi Francis,
On Sep 20, 2006, at 9:15 AM, Francis Labrie wrote:
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();
Probably just superstition, but I always get the EODatabaseContext
directly and lock it.
try {
editingContext.parentObjectStore().invalidateObjectsWithGlobalIDs
(globalIDs);
} finally {
editingContext.unlockObjectStore();
} // finally
NSNotificationCenter.defaultCenter().postNotification(EOObjectStore.
InvalidatedAllObjectsInStoreNotification,
editingContext, null);
I am curious: is that notification needed? Doesn't the call to
parentObjectStore().invalidateObjectsWithGlobalIDs(globalIDs) send this?
} // _invalidateObjectsWithGlobalIDs
On application load, I get deadlocks on
"_invalidateObjectsWithGlobalIDs(editingContext, globalIDs)" line.
I will guess that it really blocks on
editingContext.lockObjectStore()
Which suggests that something, somewhere else is not unlocking it.
Are there any other manual locks on the DB context in your code?
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.
I have never seen a kill -3 / kill QUIT not produce a thread dump
with stack traces. Have you edited
/System/Library/WebObjects/JavaApplications/wotaskd.woa/Contents/
Resources/SpawnOfWotaskd.sh
So that the thread dumps go to a file instead of /dev/null?
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?
Sorry, no ideas there other than to find some way to get a thead dump.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
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]
