| 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
|