Re: Locking problem
Re: Locking problem
- Subject: Re: Locking problem
- From: Peter Vandoros <email@hidden>
- Date: Thu, 16 Oct 2008 10:10:25 +1100
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@hidden)
Help/Unsubscribe/Update your Subscription:
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
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden