Fist of all it affect all version since WO 5.0.The problem is in EOObjectStoreCoordinator .addCooperatingObjectStore(EOCooperatingObjectStore objectStore) In some cases you can deadlock while there is nothing to do i.e. the object store passed in the parameter is already added to the coordinator. If you are in this case and don't want to wait for the next update, you can subclass EOObjectStoreCoodinator and do something like:
@Override
public void addCooperatingObjectStore(EOCooperatingObjectStore
objectStore) {
if (this.cooperatingObjectStores().indexOfIdenticalObject(objectStore) < 0) {
if (objectStore.coordinator() != null) {
throw new IllegalStateException("Cannot add " + objectStore + " to
this EOObjectStoreCoordinator because it already has another.");
}
super.addCooperatingObjectStore(objectStore);
}
}
The idea is that the test must be done before grabbing the lock. This
is not perfectly efficient and I will have a better fix but I think it
will sort the issue in the time being. I hope will have this update
out soon.
Cheers Pierre -- Pierre Frisch [EMAIL PROTECTED] On Nov 6, 2007, at 14:00, Chuck Hill wrote:
Ouch! Can you tell us under what conditions this happens? Chuck On Nov 6, 2007, at 1:54 PM, Mr. Pierre Frisch wrote:Hi Chuck,This unfortunately is a real bug. It is quite rare but I had seen it last year and finally managed to reproduce it consistently last month. The fix is not in WO 5.4 but will be in the next minor update.Pierre -- Pierre Frisch [EMAIL PROTECTED] On Nov 6, 2007, at 9:50, Chuck Hill wrote:On Nov 6, 2007, at 6:17 AM, Ken Anderson wrote:Everyone,I have a significantly multi-threaded app that's having a locking problem with EODatabaseContext. One thread has successfully locked an EC and attempted a query. In the stack trace of that thread, after it has locked the EC, it goes to do a fetch, and this is the top of the stack trace:Object.wait(long) line: not available [native method] NSRecursiveLock(Object).wait() line: 474 NSRecursiveLock.lock() line: 72 EODatabaseContext.lock() line: 1973EOObjectStoreCoordinator .addCooperatingObjectStore(EOCooperatingObjectStore) line: 130 EODatabaseChannel.setCurrentEditingContext(EOEditingContext) line: 166It stays here forever. I've checked the few places I actually lock the DB context, and they're properly protected, and no thread is anywhere else in EOF but this one.Any thoughts?? This is 5.3...One of these must be true: 1. Your JVM is insane2. You are not handling the explicitly DB context locks correctly in at least one place and it left a lock hanging3. One of the other threads _does_ have EOF lockedI have never been driven to this desperation but... You could add a direct action that gets the DB context, used RTTI to rape out the NSRecusiveLock and then use RTTI on that to log out which thread has it locked. When the app deadlocks, hit that DA. With the locking thread name in hand, look back in the app log and see if you can see what happened.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/pierre%40apple.com This email sent to [EMAIL PROTECTED]--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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
