Re: Deadlocks
Re: Deadlocks
- Subject: Re: Deadlocks
- From: Guido Neitzer <email@hidden>
- Date: Wed, 5 Sep 2007 16:14:23 -0600
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Deadlocks (From: Simon McLean <email@hidden>) |