Peter,
Thanks for the idea!
It is not the problem, but it made me realize that there must be two
locks in the game. Since one of the threads was waiting on the EC's
lock (or my custom Lock, comes out the same), and the other thread
was in a synchronized method in EODistributedObjectStore (the default
parent object store in a JC situation), then the only conclusion was
that the first thread was already within a synchronized block for the
same EODistributedObjectStore instance. And indeed, it is:
Thread [AWT-EventQueue-0] (Suspended)
Object.wait(long) line: not available [native method]
NSRecursiveLock(Object).wait() line: 474
NSRecursiveLock.lock() line: 72
JCEC(EOEditingContext).lock() line: 4685
JCEC.globalIDForObject(EOEnterpriseObject) line: 391
EODistributedObjectStore._fireDeferredFault(EOEnterpriseObject,
EORelationship) line: 1156 (this is synchronized)
EODistributionDeferredFaultHandler.createFaultForDeferredFault
(Object, EOEnterpriseObject) line: 20
Project(EOCustomObject).willReadRelationship(Object) line: 1302
...
I think this should get me going. I'll try making all my overridden
EC's methods synchronize on the EODistributedObjectStore. It will be
a PITA, but it should prevent this deadlock.
Thanks!
F
- also, to me this seems like not-too-well organized locking
behavior. If there are two object stores (parent - child), both of
which require synchronized access using their own locks, and their
interaction is bidirectional, well, that's a recipe for deadlocks.
And also the combination of using NSLocks and synchronized methods
isn't all that grand of an idea. Not a highlight of EOF this point.
On Oct 15, 2008, at 19:10, Peter Vandoros wrote:
Try commenting out the use of the java.util.concurrent.locks.Lock
code in you EC subclass and see if that helps. I suspect that
somewhere under the hood your EC is being locked by directly using
the private NSLock instance instead of calling the lock() and unlock
() method.
Regards
Peter
On 16/10/2008, at 2:20 AM, Florijan Stamenkovic wrote:
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/flor385%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/peter%
40etechgroup.com.au
This email sent to [EMAIL PROTECTED]
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
