On Jun 21, 2009, at 9:44 PM, Guido Neitzer wrote:

This basically answers the question itself. You must (MUST MUST MUST) lock / unlock your editing contexts! Only the defaultEditingContext is locked / unlocked for you!

Look into the autolocking features of MultiECLockManager [1] or ERXEC [2] if you don't want to bother locking your ECs. Don't try locking yourself. You will most probably fail as there are many cases you won't find if you had to ask the question below. Go with the available options and REALLY use them. Your life will be miserable without!

Guido

[1] http://codeferous.com/files/MultiECLockManager.java
[2] http://wiki.objectstyle.org/confluence/display/WONDER/Tutorials

While what Guido says is true, I am not sure that this is the problem. Look at the stack trace:

"WorkerThread142" prio=5 tid=0x001eda18 nid=0xb3 in Object.wait() [0xcbbfe000..0xcbbffc30]
        at java.lang.Object.wait(Native Method)
        - waiting on <0xd9ada680> (a com.webobjects.foundation.NSRecursiveLock)
        at java.lang.Object.wait(Object.java:429)
at com.webobjects.foundation.NSRecursiveLock.lock(NSRecursiveLock.java:72)
        - locked <0xd9ada680> (a com.webobjects.foundation.NSRecursiveLock)
at com.webobjects.eoaccess.EODatabaseContext.lock(EODatabaseContext.java: 1974) at com .webobjects .eocontrol .EOObjectStoreCoordinator .addCooperatingObjectStore(EOObjectStoreCoordinator.java:130) at com .webobjects .eoaccess .EODatabaseChannel.setCurrentEditingContext(EODatabaseChannel.java:167) at com .webobjects .eoaccess .EODatabaseChannel ._selectWithFetchSpecificationEditingContext(EODatabaseChannel.java:789) at com .webobjects .eoaccess .EODatabaseChannel .selectObjectsWithFetchSpecification(EODatabaseChannel.java:216) at com .webobjects .eoaccess .EODatabaseContext ._objectsWithFetchSpecificationEditingContext(EODatabaseContext.java: 3206) at com .webobjects .eoaccess .EODatabaseContext .objectsWithFetchSpecification(EODatabaseContext.java:3347) at com .webobjects .eocontrol .EOObjectStoreCoordinator .objectsWithFetchSpecification(EOObjectStoreCoordinator.java:539) at com .webobjects .eocontrol .EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java: 4075) at com .webobjects .eocontrol .EOEditingContext.objectsWithFetchSpecification(EOEditingContext.java: 4461)

It is waiting to lock an EODatabaseContext, not an EOEditingContext. Using unlocked ECs will lead to data corruption. Mislocking ECs will lead to session level dead locks.

This looks like something in your code is locking an EODatabaseContext and then not unlocking it. None of the other other threads are holding the lock.

Check for code like

dbContext.lock();
... do something there...
dbContext.unlock();

This SHOULD be in a try...finally block:

dbContext.lock();
try {
        ... do something there...
} finally {
        dbContext.unlock();
}


Chuck




On 21. Jun. 2009, at 20:45 , Vicky C. Miller wrote:

We are not using EOSharedEditingContext anywhere in our application. We are
using following Editing Contexts in our application :

1. At some places of our application we are using session's
defaultEditingContext()
2. At some places of our application we are creating a new EOEditingContext
where ever it is required.

vm
-----Original Message-----
From: Travis Britt [mailto:[email protected]]
Sent: Saturday, June 20, 2009 11:01 AM
To: [email protected]
Cc: [email protected]
Subject: Re: Excessive WebObjects Locks

Are you using EOSharedEditingContext anywhere?

tb

On Jun 19, 2009, at 6:45 PM, Vicky C. Miller wrote:
Our issue is occurring where the code uses EOEditingContext and other
objects in the WebObjects API that acquire a
com.webobjects.foundation.NSRecursiveLock.



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list ([email protected] )
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/guido.neitzer%40gmail.com

This email sent to [email protected]

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects- [email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/chill%40global-village.net

This email sent to [email protected]


--
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-deploy mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to