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(EOObjectStoreCoordinator.java:130)
at
com
.webobjects
.eoaccess
.EODatabaseChannel.setCurrentEditingContext(EODatabaseChannel.java:
166)
at
com
.webobjects
.eoaccess
.EODatabaseChannel
._selectWithFetchSpecificationEditingContext(EODatabaseChannel.java:
788)
at
com
.webobjects
.eoaccess
.EODatabaseChannel
.selectObjectsWithFetchSpecification(EODatabaseChannel.java:215)
at
com
.webobjects
.eoaccess
.EODatabaseContext
._objectsWithFetchSpecificationEditingContext(EODatabaseContext.java:
3205)
at
com
.webobjects
.eoaccess
.EODatabaseContext
.objectsWithFetchSpecification(EODatabaseContext.java:3346)
at
com
.webobjects
.eocontrol
.EOObjectStoreCoordinator
.objectsWithFetchSpecification(EOObjectStoreCoordinator.java:539)
at
com
.webobjects
.eocontrol
.EOEditingContext
.objectsWithFetchSpecification(EOEditingContext.java:4114)
at
com
.webobjects
.eocontrol
.EOEditingContext
.objectsWithFetchSpecification(EOEditingContext.java:4500)
at
com
.webobjects
.eoaccess.EOUtilities.objectsWithQualifierFormat(EOUtilities.java: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
--
Chuck Hill Senior Consultant / VP Development
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]
