• 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: EODatabaseContext locking situation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EODatabaseContext locking situation


  • Subject: Re: EODatabaseContext locking situation
  • From: "Mr. Pierre Frisch" <email@hidden>
  • Date: Tue, 6 Nov 2007 13:54:46 -0800

Hi Chuck,

This unfortunately is a real bug. It is quite rare but I had seen it last year and finally managed to reproduce it consistently last month. The fix is not in WO 5.4 but will be in the next minor update.

Pierre
--
Pierre Frisch
email@hidden


On Nov 6, 2007, at 9:50, Chuck Hill wrote:


On Nov 6, 2007, at 6:17 AM, Ken Anderson wrote:

Everyone,

I have a significantly multi-threaded app that's having a locking problem with EODatabaseContext. One thread has successfully locked an EC and attempted a query. In the stack trace of that thread, after it has locked the EC, it goes to do a fetch, and this is the top of the stack trace:

Object.wait(long) line: not available [native method]
NSRecursiveLock(Object).wait() line: 474
NSRecursiveLock.lock() line: 72
EODatabaseContext.lock() line: 1973
EOObjectStoreCoordinator .addCooperatingObjectStore(EOCooperatingObjectStore) line: 130
EODatabaseChannel.setCurrentEditingContext(EOEditingContext) line:166



It stays here forever. I've checked the few places I actually lock the DB context, and they're properly protected, and no thread is anywhere else in EOF but this one.


Any thoughts?? This is 5.3...

One of these must be true:
1. Your JVM is insane
2. You are not handling the explicitly DB context locks correctly in at least one place and it left a lock hanging
3. One of the other threads _does_ have EOF locked


I have never been driven to this desperation but... You could add a direct action that gets the DB context, used RTTI to rape out the NSRecusiveLock and then use RTTI on that to log out which thread has it locked. When the app deadlocks, hit that DA. With the locking thread name in hand, look back in the app log and see if you can see what happened.

Chuck

--

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects






_______________________________________________
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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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: EODatabaseContext locking situation
      • From: Chuck Hill <email@hidden>
References: 
 >EODatabaseContext locking situation (From: Ken Anderson <email@hidden>)
 >Re: EODatabaseContext locking situation (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Slogan
  • Next by Date: Re: EODatabaseContext locking situation
  • Previous by thread: Re: EODatabaseContext locking situation
  • Next by thread: Re: EODatabaseContext locking situation
  • Index(es):
    • Date
    • Thread