• 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: Locking problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking problem


  • Subject: Re: Locking problem
  • From: Florijan Stamenkovic <email@hidden>
  • Date: Wed, 15 Oct 2008 11:20:23 -0400

OK, some more info, perhaps it will strike a chord with someone?

My latest attempt for solving the threading issue was to essentially make every method in my editing context synchronized (though not the old fashioned way, but using a java.util.concurrent.locks.Lock in ec's lock() and unlock() methods) to see if that helps. I've ditched autoLock and autoUnlock, and I simply lock() and unlock() in every overridden method in the ec. Well, I've stopped getting NSRecursiveLock exceptions, but I still get deadlocks. What is weird is that while AWT's event dispatch thread is waiting for the EC lock to be released, the other thread working with the EC is blocking on this line:

EODistributedObjectStore.objectsWithFetchSpecification (EOFetchSpecification, EOEditingContext) line: 499

Obviously, this method is called through the blocking EC, so it has come past the EC lock. So, I'm really wondering what's happening at that line. I've noticed through Eclipse's debugger that the method is synchronized. I am oblivious as to why that thread would block in such a line. If it was on Object.wait() or something there I could understand, but this is bizarre.

Anyone has an idea?

F

On Oct 13, 2008, at 20:14, Mike Schrag wrote:

I don't understand what you say about autoLocking being RR based.
Yep, sorry -- you're right ... Lock coalescing is the one that depends on the RR loop. That said, I definitely ran into cases where auto-locking alone was not enough (at least on the web ... maybe it's less of an issue with JC). What would happen is that you'd have a series of, say, 5 operations that were logically a single transaction, but would be 5 individual lock-unlock autolocks, and there would be changes to the snapshot state inbetween calls that would cause some weird race conditions. This is actually why I decided to do the lock coalescing stuff in Wonder, which seemed to clear up the issues. But not having done JC, maybe this is less of an issue. It only appeared under higher- than-"normal" load.

ms

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com


This email sent to email@hidden

_______________________________________________ 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: Locking problem
      • From: Peter Vandoros <email@hidden>
References: 
 >Locking problem (From: Florijan Stamenkovic <email@hidden>)
 >Re: Locking problem (From: Mike Schrag <email@hidden>)
 >Re: Locking problem (From: Florijan Stamenkovic <email@hidden>)
 >Re: Locking problem (From: Mike Schrag <email@hidden>)

  • Prev by Date: Re: Converting my App to Wonder
  • Next by Date: Re: You crossed editing context boundaries...Fixzed, no NullPointerException, now fixing db
  • Previous by thread: Re: Locking problem
  • Next by thread: Re: Locking problem
  • Index(es):
    • Date
    • Thread