Re: Bug in client side EOF locking?
Re: Bug in client side EOF locking?
- Subject: Re: Bug in client side EOF locking?
- From: Stamenkovic Florijan <email@hidden>
- Date: Wed, 28 Jan 2009 14:49:20 -0400
On Jan 28, 2009, at 13:54, Chuck Hill wrote:
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.
Yep, noticed that. Considered making a completely synchronized EO
superclass, but that seems a bit excessive; would probably wreck
performance. However, synchronizing those two methods might be the way
to go....
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. :-)
Well, the way I see it, if it was meant to be single threaded only,
then there'd be no locking done at all :)
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.
That's where I'll probably end...
I'd certainly avoid doing this.
Ah, but then my life would not be half as fun! :)))
F
_______________________________________________
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