• 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: Bug in client side EOF locking?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug in client side EOF locking?


  • Subject: Re: Bug in client side EOF locking?
  • From: Chuck Hill <email@hidden>
  • Date: Wed, 28 Jan 2009 09:54:51 -0800


On Jan 28, 2009, at 7:10 AM, Stamenkovic Florijan wrote:

On Jan 27, 2009, at 19:44, Chuck Hill wrote:

This happens while I have two threads doing some work. One is performing calculations, the other is updating the GUI. Both of them are accessing the same EOs, asking them for data.

That sounds problematic. Usually one thread would hold the EC lock and only that thread would touch the EOs.

Well, I've synchronized access to all the methods in my EC (synchronizing on the default parent object store object, to avoid some deadlocks, which are JC specific I believe), and till now that seemed sufficient, it solved all the locking issues I had so far encountered...

Accessing any EO can trigger EOF access and if you are locking around EC methods, it won't be locked at that time. You would at least need to synchronize around willRead() and willReadRelationship(). Note that willReadRelationship() locks the object store, not the EC.



2. EOCustomObject.willReadRelationship is calling "unlockObjectStore(...)" while the thread this is happening on does not actually own the lock in the EODistributedObjectStore... To me this looks like a bug outside the scope of my code. Or am I missing something?

It will lock the object store to fire a fault for the relationship. Then it will unlock it. Perhaps both threads were firing faults at the same time?

They are, guaranteed. But they should synchronize between themselves... I thought that was what locking the object store was all about...


Also, when I look at the source of ReentrantLock, I see that this exception is thrown because of:

if (Thread.currentThread() != owner)
               throw new IllegalMonitorStateException();

So, the thread trying to unlock does not actually own the lock, the other thread owns it. AFAIK the only way to make this happen is calling unlock, without the same thread obtaining a lock before that. Which is most definitively a bug. Or do I see this wrong?

I am not sure. It sounds like a bug, but you concurrent access also sounds like a bug. :-)



This is one of those situations in which being able to see WO source would really make life easier :)

I can't help you there.


3. Ideas, suggestions (bug reporting aside)?

EOF does not really like more than one thread accessing EOs at one time. Can you use two sets of EOs in different editing contexts? Post notifications from the thread doing the calculations?

Hm, I can fix this particular situation quite easily (make the thread that is calculating stuff fire all the faults that the other thread would normally fire). I am more interested in the principle of things... So, what is the end verdict? Report a bug? Avoid more then one thread doing EO work?


I don't see any harm in doing both.  I'd certainly avoid doing this.

Chuck

--
Chuck Hill             Senior Consultant / VP Development

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
  • Follow-Ups:
    • Re: Bug in client side EOF locking?
      • From: Stamenkovic Florijan <email@hidden>
References: 
 >Bug in client side EOF locking? (From: Stamenkovic Florijan <email@hidden>)
 >Re: Bug in client side EOF locking? (From: Chuck Hill <email@hidden>)
 >Re: Bug in client side EOF locking? (From: Stamenkovic Florijan <email@hidden>)

  • Prev by Date: Re: JadClipse and Eclipse 3.4
  • Next by Date: Re: Handling Session timeout with ajax
  • Previous by thread: Re: Bug in client side EOF locking?
  • Next by thread: Re: Bug in client side EOF locking?
  • Index(es):
    • Date
    • Thread