Re: NSRecursiveLock.lock() causing deadlock??
Re: NSRecursiveLock.lock() causing deadlock??
- Subject: Re: NSRecursiveLock.lock() causing deadlock??
- From: Art Isbell <email@hidden>
- Date: Wed, 27 Aug 2008 16:18:43 -1000
On Aug 27, 2008, at 3:47 PM, Dov Rosenberg wrote: I am not sure why a cooperating object store is being added.
"http-10042-Processor46" nid=59971 state=WAITING
- waiting on <0xcb1792> (a com.webobjects.foundation.NSRecursiveLock)
- locked <0xcb1792> (a com.webobjects.foundation.NSRecursiveLock)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Unknown Source)
at com.webobjects.foundation.NSRecursiveLock.lock(NSRecursiveLock.java:72)
at com.webobjects.eoaccess.EODatabaseContext.lock(EODatabaseContext.java:1973)
at com.webobjects.eocontrol.EOObjectStoreCoordinator.addCooperatingObjectStore(EOObjectStoreCoordinator.java:130)
Hmm, you may be suffering from a bug whose effect can be minimized. I think this bug can occur when a cooperating object store is being added, and that the default implementation of addCooperatingObjectStore() doesn't check whether the cooperating object store being added has already been added. By not invoking the default implementation unnecessarily, exposure to this bug can be minimized considerably. This bug may have been fixed in WO 5.4.2, but the following workaround seems pretty harmless even after this bug has been fixed.
In your Application constructor:
EOObjectStoreCoordinator.setDefaultCoordinator(new ObjectStoreCoordinator());
ObjectStoreCoordinator.java:
public class ObjectStoreCoordinator extends EOObjectStoreCoordinator {
@Override public void addCooperatingObjectStore(EOCooperatingObjectStore anObjectStore) {
if (cooperatingObjectStores().indexOfIdenticalObject(anObjectStore) == NSArray.NotFound) {
if (anObjectStore.coordinator() != null) { throw new IllegalStateException("Cannot add " + anObjectStore + " to this EOObjectStoreCoordinator because it already has another."); } super.addCooperatingObjectStore(anObjectStore); } } }
I also found this line of code – I don’t think it is being called at this time, but it seems like perhaps this should have a try/catch/finally block and a lock()/unlock(). Thoughts?
EOObjectStoreCoordinator.defaultCoordinator().invalidateAllObjects();
I avoid invoking invalidateAllObjects() at almost all costs. Is there no other way to do what this is doing? |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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