Re: [WORKED AROUND] Re: Bug in client side EOF locking?
Re: [WORKED AROUND] Re: Bug in client side EOF locking?
- Subject: Re: [WORKED AROUND] Re: Bug in client side EOF locking?
- From: Chuck Hill <email@hidden>
- Date: Thu, 26 Feb 2009 18:22:46 -0800
- Delivered-to: email@hidden
- Delivered-to: email@hidden
On Feb 26, 2009, at 10:19 AM, Stamenkovic Florijan wrote:
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.
How? Where?
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.
Have stack traces?
How come this particular exception happens in a multi-threaded
scenario and not in a single threaded scenario?
Hint: more than one thread. :-) Concurrency
(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.
An exception resulting in an unlock upon which the other thread locks
it and then a finally block unlocking it again in the first thread?
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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