Re: Deadlocks
Re: Deadlocks
- Subject: Re: Deadlocks
- From: Mike Schrag <email@hidden>
- Date: Thu, 6 Sep 2007 03:04:53 -0400
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...
There was a bug with coalesced autolocks where it would coalesce
outside of the RR-loop, which meant that it would leave a lock open
on purpose. This would explode like you are describing in the long
response thread because it would keep the lock on. There is a "fix"
for this whereby it reverts back to just plain-jane autolocking on
each call vs locking for the entire thread. This is still "wrong"
because you usually want a longer lock than just on each call. The
proper way to do it is to local instance the object into another EC
and lock THAT for the long response. This still requires manually
locking/unlocking to get a lock span across multiple calls, but even
if you don't, Wonder will at least autolock each individual call for
you and prevent MOST terrible things.
Then there's the variation of long response (I'd have to look up
exactly what this is called -- i think there is the normal long
response and then another one that does this style) that will act
like the long response thread is in a RR loop and support coalesced
locking also. I can't remember which of this stuff rolled into the
"main" long response class offhand, but this also supports cleaning
up left-open-locks just like in a RR loop. There's also a Thread/
Runnable variant that does this same thing, so you can use the ERX
version of the runnable and it will always clean up for you ... Just
some safety nets.
_______________________________________________
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