• 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: Stamenkovic Florijan <email@hidden>
  • Date: Fri, 27 Feb 2009 10:10:06 -0400


On Feb 26, 2009, at 22:22, Chuck Hill wrote:

<snip>

How? Where?

willRead(), willReadRelationship(Object)

<snip>

Have stack traces?

See below. Sorry about not providing them before, that was silly.

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

Hint: more than one thread. :-) Concurrency

woooow, ya think? :-P


(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?

Interesting idea, however... Let's say that this exception you mention gets thrown in a single threaded scenario. It would still result in more calls to unlock() then to lock(). The IllegalMonitorStateException would be thrown at either of the last two unlock() calls. So, we can assume it does not happen in a single threaded scenario, since the monitor exception is not thrown. Which means that it only happens in a multi threaded scenario. So, it still falls under the category of the idiotic idiom:


if(accessingThreadCount > 1)
	throw SomeException();

Or not?

F

Output logged from my EC's lockObjectStore() and unlockObjectStore() methods. There is only one EC.

...
will lock: JBND worker thread
did lock: JBND worker thread
will unlock: JBND worker thread
did unlock: JBND worker thread
will lock: AWT-EventQueue-0
did lock: AWT-EventQueue-0
will lock: JBND worker thread
did lock: JBND worker thread
will unlock: AWT-EventQueue-0
did unlock: AWT-EventQueue-0
will unlock: JBND worker thread


Stack traces... Got them by putting an exception breakpoint for IllegalMonitorStateException. The breakpoint set to suspend the VM. Traces are from the only two threads that do EOF work:


Thread [JBND worker thread] (Suspended (exception IllegalMonitorStateException))
ReentrantLock$NonfairSync(ReentrantLock$Sync).tryRelease(int) line: 125
ReentrantLock$NonfairSync(AbstractQueuedSynchronizer).release(int) line: 1137
ReentrantLock.unlock() line: 431
EODistributedObjectStore.unlock() line: 107
JCEC(EOEditingContext).unlockObjectStore() line: 4668
JCEC.unlockObjectStore() line: 283
User(EOFDataObject).willRead() line: 744
_EOMutableKnownKeyDictionary$Initializer $_GenericRecordBinding.valueInObject(Object) line: 570
User(EOCustomObject).storedValueForKey(String) line: 1634
User(_User).password() line: 77
...



Thread [AWT-EventQueue-0] (Suspended)
JCEC.lockObjectStore() line: 274
Account(EOFDataObject).willRead() line: 742
_EOMutableKnownKeyDictionary$Initializer $_GenericRecordBinding.valueInObject(Object) line: 570
Account(EOCustomObject).storedValueForKey(String) line: 1634
Account(_Account).number() line: 94
GeneratedMethodAccessor50.invoke(Object, Object[]) line: not available
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
NSKeyValueCoding$ValueAccessor$1.methodValue(Object, Method) line: 636
NSKeyValueCoding$_MethodBinding.valueInObject(Object) line: 1134
Account(EOCustomObject).valueForKey(String) line: 1498
Account(EOFDataObject).valueForKey(String) line: 714
Account(EOFDataObject).get(String) line: 212
...
_______________________________________________
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: Chuck Hill <email@hidden>
References: 
 >Re: [WORKED AROUND] Re: Bug in client side EOF locking? (From: Stamenkovic Florijan <email@hidden>)
 >Re: [WORKED AROUND] Re: Bug in client side EOF locking? (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Yet another threading question...
  • Next by Date: wolips.properties file
  • 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