On 05.09.2007, at 16:01, Simon McLean wrote:
We're experiencing some pretty bad deadlock issues at the moment and I'm pretty convinced it's down to EC lock abuse.
Get a stacktrace of your running application to verify that: http://tinyurl.com/3bpkkv
... we should never have to manually lock or unlock an EC ?
That is true, yes - but you still might run into problems if you do bad things.
Or put another way, when using these rules is there any situation that we would have to call ec.lock() or ec.unlock() in our code ?
I normally lock and unlock manually on long response pages / tasks, as the unlocking of editing contexts relies on the request response loop.
If you see problems in the stacktrace, when the session gets checked out from the session store, make sure you NEVER EVER touch something from the session's default editing context inside your "performAction" method on a long response page. This will autolock your session's default editing context, it will not get unlocked, because you are outside of the rr loop and the next checkout for that session will fail.
The other thing I saw with deadlocks: if you run out of space on your server, log4j might deadlock.
cug _______________________________________________ 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]
