• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Deadlocks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Deadlocks
      • From: Cornelius Jaeger <email@hidden>
References: 
 >Deadlocks (From: Simon McLean <email@hidden>)
 >Re: Deadlocks (From: Guido Neitzer <email@hidden>)
 >Re: Deadlocks (From: Mike Schrag <email@hidden>)
 >Re: Deadlocks (From: Anjo Krank <email@hidden>)

  • Prev by Date: Re: Deadlocks
  • Next by Date: Re: Deadlocks
  • Previous by thread: Re: Deadlocks
  • Next by thread: Re: Deadlocks
  • Index(es):
    • Date
    • Thread