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:tbr...@phigment.org]
Sent: Saturday, June 20, 2009 11:01 AM
To: webobjects-deploy@lists.apple.com
Cc: vcmil...@cssg.com
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 (Webobjects-deploy@lists.apple.com
)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/guido.neitzer%40gmail.com
This email sent to guido.neit...@gmail.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-deploy mailing list (Webobjects-
dep...@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/chill%40global-village.net
This email sent to ch...@global-village.net
--
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 (Webobjects-deploy@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-deploy/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
