Re: Locking problem
Re: Locking problem
- Subject: Re: Locking problem
- From: Florijan Stamenkovic <email@hidden>
- Date: Wed, 15 Oct 2008 11:20:23 -0400
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@hidden)
Help/Unsubscribe/Update your Subscription:
40mac.com
This email sent to email@hidden
_______________________________________________
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