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

Re: [WORKED AROUND] Re: Bug in client side EOF locking?


  • Subject: Re: [WORKED AROUND] Re: Bug in client side EOF locking?
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 26 Feb 2009 18:22:46 -0800


On Feb 26, 2009, at 10:19 AM, Stamenkovic Florijan wrote:


On Jan 28, 2009, at 15:17, Stamenkovic Florijan wrote:

As you suggested, adding this to my EO superclass seems to do it:

	private static final Integer monitor = new Integer(345345);

	public void willRead(){
		synchronized(monitor){
			super.willRead();
		}
	}

	public Object willReadRelationship(Object object){
		synchronized(monitor){
			return super.willReadRelationship(object);
		}
	}

Just hope it does not introduce deadlocks in the future...

Well, it did.

How? Where?



Adding arbitrary synchronization is dangerous business...

Right. So I figured, I'll use the existing lock:

	public void willRead(){
		EOEditingContext ec = editingContext();
		ec.lockObjectStore();
		try{ super.willRead(); }
		finally{ ec.unlockObjectStore(); }
	}

	public Object willReadRelationship(Object object){
		EOEditingContext ec = editingContext();
		ec.lockObjectStore();
		try{ return super.willReadRelationship(object); }
		finally{ ec.unlockObjectStore(); }
	}

Should be a nice, atomic operation, and it relies on existing locking (a recursive lock), so I should be all good, right? Wrong... Got rid of the deadlock, but increased the frequency of the same exception I've seen before.
The exception is caused by unlock() being called on the EODistributedObjectStore from a Thread that is not the lock owner. I am more and more perplexed by this.

Have stack traces?


How come this particular exception happens in a multi-threaded scenario and not in a single threaded scenario?

Hint: more than one thread. :-) Concurrency


(Also note that the lock object is not public, it's lock() and unlock() methods are exposed through the public API of EODistributedObjectStore). Assuming that ReenetrantLock is not buggy, the only way I can imagine to get this exception is doing the equivalent of:

if(accessingThreadCount > 1)	// super-evil
	eoDistributedObjectStoreInstance.unlock();

If anyone else knows another way, please let me know. I can't think of one, and am amazed to see it happening.

In the meanwhile, I admit defeat, and go back to single threaded EOF operations.


An exception resulting in an unlock upon which the other thread locks it and then a finally block unlocking it again in the first thread?


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: [WORKED AROUND] Re: Bug in client side EOF locking?
      • From: Stamenkovic Florijan <email@hidden>
References: 
 >Re: [WORKED AROUND] Re: Bug in client side EOF locking? (From: Stamenkovic Florijan <email@hidden>)

  • Prev by Date: Re: Yet another threading question...
  • Next by Date: Re: Eclipse 3.4.1 and WOLIPS 3.4.5XXX
  • Previous by thread: Re: [WORKED AROUND] Re: Bug in client side EOF locking?
  • Next by thread: Re: [WORKED AROUND] Re: Bug in client side EOF locking?
  • Index(es):
    • Date
    • Thread