Re: Deadlocks
Re: Deadlocks
- Subject: Re: Deadlocks
- From: Anjo Krank <email@hidden>
- Date: Thu, 6 Sep 2007 08:08:19 +0200
Am 06.09.2007 um 00:39 schrieb Mike Schrag:
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.
This particular deadlock should be fixed as of a couple weeks ago
after we talked, btw ... I think I rolled autolocking into long
response, also.
How is that supposed to work? The actual processing is done in the
extra thread, and if it has locked the supplied EC, any page coming
it with this session will not run - so if you run with concurrent
request handling off, the app request handling lock is never returned
until the task finished and your app is dead in the meantime.
Otherwise "only" the long response page is frozen...
Apart from that, when you use D2W it is ridiculously easy to deadlock
your app when you don't use Wonder because of the pattern of locking/
unlocking ECs in awake() and sleep() which doesn't really work on
reloads.
Cheers, Anjo
_______________________________________________
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