On Jan 28, 2009, at 15:17, Stamenkovic Florijan wrote:
As you suggested, adding this to my EO superclass seems to do it:
private static final Integer monitor = new Integer(345345);
public void willRead(){
synchronized(monitor){
super.willRead();
}
}
public Object willReadRelationship(Object object){
synchronized(monitor){
return super.willReadRelationship(object);
}
}
Just hope it does not introduce deadlocks in the future...
Well, it did.
Adding arbitrary synchronization is dangerous business...
Right. So I figured, I'll use the existing lock:
public void willRead(){
EOEditingContext ec = editingContext();
ec.lockObjectStore();
try{ super.willRead(); }
finally{ ec.unlockObjectStore(); }
}
public Object willReadRelationship(Object object){
EOEditingContext ec = editingContext();
ec.lockObjectStore();
try{ return super.willReadRelationship(object); }
finally{ ec.unlockObjectStore(); }
}
Should be a nice, atomic operation, and it relies on existing locking
(a recursive lock), so I should be all good, right? Wrong... Got rid
of the deadlock, but increased the frequency of the same exception
I've seen before. The exception is caused by unlock() being called on
the EODistributedObjectStore from a Thread that is not the lock owner.
I am more and more perplexed by this. How come this particular
exception happens in a multi-threaded scenario and not in a single
threaded scenario? (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.
Best regards,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
