Under heavy EOF processing load across many background threads I was
getting occasional deadlocks (this was a few weeks/months ago) and
turning off the safelocking stuff for manually managed ec's fixed that
problem. Actually I have a static utility method
Utilities.newManualLockingEditingContext(...), but I removed that
dependency for the sake of sharing this class with you just now.
Think about it, if I am in a background thread (and no, I don't use,
or want to use auto locking in my background threads!), I *could* get
a NSNotification that invokes a method that autoLocks in between the
time that I constructed and the time I called ec.lock() .... again it
is just a concurrency risk.... and I can say for a fact that in
production, I began getting occasional deadlocks when EOF was under
heavy load once I turned on "safeLocking" a while back and the
approach below fixed it and there has not been a single deadlock in
production since this approach was taken for manual lock control ec's.
Here is my usual utility for creating manual lock control ec's:
<snip>
/**
* I do not want autolocking in non-request threads
*
* @param parent
* @return an ERXEC with safeLocking properties turned OFF.
*/
public static EOEditingContext
newManualLockingEditingContext(EOObjectStore parent) {
ERXEC ec = (ERXEC) ERXEC.newEditingContext(parent);
ec.setCoalesceAutoLocks(false);
ec.setUseAutoLock(false);
return ec;
}
public static EOEditingContext newManualLockingEditingContext() {
return newManualLockingEditingContext(null);
}
</snip>
For now my mindset is that if it is manual lock control, then I don't
want autolocking. lock/try/finally/unlock is my preferred approach in
that usage.
Works for me ... YMMV ;-)
Regards, Kieran
PS. And even the above is not perfect protection against an autolock
if a thread gets cpu execution delay between construction statement
and the ec.setCoalesceAutoLocks(false) statement. After setting
safelocking props to false, I should really check if the ec was
autolocked and unlock it before returning .... or even have an ERXEC
constructor that takes a safeLocking boolean param, but that would be
two more undesired constructors ....... so probably making
isLockedInThread public (or accessible using reflection) should do the
trick.
On Dec 3, 2009, at 10:29 AM, Miguel Arroz wrote:
Hi!
On 2009/12/03, at 15:02, Kieran Kelleher wrote:
ERXEC ec = (ERXEC) ERXEC.newEditingContext(osc);
ec.setCoalesceAutoLocks(false);
ec.setUseAutoLock(false);
ec.lock();
Won't the manual lock() disable the autolocking automatically
until the EC is manually unlocked again? I believe the ec stays
locked until it's manually unlocked.
Yours
Miguel Arroz
_______________________________________________
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]
