Would this cause a lock to be held that would bring down the entire app
after awhile? Could EODatabaseContext.lock be causing the NSRecursiveLock to
be held? Is the WO 5.4.2 the same one that came with the iPhone SDK and
Xcode? I couldn¹t find a download for 5.4.2

The offending line of code in our app that was being executed was

    siteList = EOUtilities.objectsWithQualifierFormat(ec, "Site",
"(referenceKey = %@) AND (parent = null) ", args);

We make extensive use of EOUtilities thru out our app. The full thread dump
was

 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)
    at 
com.webobjects.eoaccess.EODatabaseChannel.setCurrentEditingContext(EODatabas
eChannel.java:166)
    at 
com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificationEditi
ngContext(EODatabaseChannel.java:788)
    at 
com.webobjects.eoaccess.EODatabaseChannel.selectObjectsWithFetchSpecificatio
n(EODatabaseChannel.java:215)
    at 
com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEdit
ingContext(EODatabaseContext.java:3205)
    at 
com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(EODa
tabaseContext.java:3346)
    at 
com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecificat
ion(EOObjectStoreCoordinator.java:539)
    at 
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEd
itingContext.java:4114)
    at 
com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEd
itingContext.java:4500)
    at 
com.webobjects.eoaccess.EOUtilities.objectsWithQualifierFormat(EOUtilities.j
ava:145)


Thanks again for your insights

Dov Rosenberg



On 8/27/08 10:18 PM, "Art Isbell" <[EMAIL PROTECTED]> wrote:

> 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(E
>> OObjectStoreCoordinator.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?
> 
>  
> Aloha,
> Art
>  
> 
> 
> 
>  _______________________________________________
> 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/drosenberg%40inquira.com
> 
> This email sent to [EMAIL PROTECTED]

 _______________________________________________
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]

Reply via email to