We only have a single database and a single model in our application. The
only other NSRecursiveLocks that are being held are from the
EOObjectStoreCoordinator.lock().
I have noticed that we have not been very consistent in using
EOEditingContexts. Most of the newer code creates a subclass of
EOEditingContext (LockScreamingEditingContext thanks Chuck!!), there are
some references to session.defaultEditingContext(), and some from the
WOComponent.defaultEditingContext (I think the WOComponent and session
EOEditingContext are the same). We replace the connection dictionary at
startup. Could the difference in EOEditingContexts cause a second
EOCooperatingObjectStore to be added?
Once again thanks for your help
Dov Rosenberg
On 8/27/08 10:57 PM, "Chuck Hill" <[EMAIL PROTECTED]> wrote:
>
> On Aug 27, 2008, at 7:42 PM, Dov Rosenberg wrote:
>
>> Would this cause a lock to be held that would bring down the entire app
>> after awhile?
>
> Yes.
>
>
>> Could EODatabaseContext.lock be causing the NSRecursiveLock to be held?
>
> I think what is happening is that some other thread has this lock and
> EODatabaseContext.lock() is blocking.
>
> Are you connecting to more than one database? If not, I suspect that you have
> a small (insidious perhaps) difference in the connection dictionaries of your
> models. That is the only thing that I can think of that would cause a second
> EOCooperatingObjectStore (EODatabaseContext) to be added.
>
>
>> 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
>
> It is part of the latest Xcode download, 1 GB more or less.
>
>
>> 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.
>
> That is not causing the problem that is just the place where it surfaces.
> EOUtilities is safe.
>
>
>> 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(E
>> OObjectStoreCoordinator.java:130)
>> at
>> com.webobjects.eoaccess.EODatabaseChannel.setCurrentEditingContext(EODatabase
>> Channel.java:166)
>> at
>> com.webobjects.eoaccess.EODatabaseChannel._selectWithFetchSpecificationEditin
>> gContext(EODatabaseChannel.java:788)
>> at
>> com.webobjects.eoaccess.EODatabaseChannel.selectObjectsWithFetchSpecification
>> (EODatabaseChannel.java:215)
>> at
>> com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEditi
>> ngContext(EODatabaseContext.java:3205)
>> at
>> com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(EODat
>> abaseContext.java:3346)
>> at
>> com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecificati
>> on(EOObjectStoreCoordinator.java:539)
>> at
>> com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEdi
>> tingContext.java:4114)
>> at
>> com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(EOEdi
>> tingContext.java:4500)
>> at
>> com.webobjects.eoaccess.EOUtilities.objectsWithQualifierFormat(EOUtilities.ja
>> va:145)
>>
>>
>> Thanks again for your insights
>>
>> Dov Rosenberg
>
>
>
> Chuck
>
>
>> 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
>>>> (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?
>>>
>>>
>>> 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/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
