Chuck,I am not. Again I might be missing something, but I understand ERXEC does autolock -- even in a background thread -- as needed, albeit possibly not in the most efficient manner (e.g., http://lists.apple.com/archives/Webobjects-dev/2007/May/msg00578.html).
Assuming you have the properties set properly.
Based on what I have found on the Web, I have this in my Properties:
=== er.extensions.ERXEC.safeLocking=true er.extensions.ERXEC.useSharedEditingContext=false er.extensions.ERXApplication.useEditingContextUnlocker=true er.extensions.ERXEC.defaultAutomaticLockUnlock=true er.extensions.ERXEC.defaultCoalesceAutoLocks=true ===
(Besides frankly, I don't really see the need to lock an EC at all, given the EC is created, used and released in one separate thread and never shared anyhow with other threads; but then, superfluous locking does not harm anything but efficiency, and efficiency is not paramount with background threads.)
You not seeing the need, does not mean the need is not there. :-) EOF sends out a lot of notifications, an unlocked EC will process those notifications immediately and that can mutate the EO state (attributes, relationships). You won’t have a consistent view of the world in an unlocked EC. The object state can change on you at any time, without warning. Have fun with that! :-)
Anyway, just to be triple sure, I have changed my task code to
=== class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation { ... def editingContext ... def performAction { ... try { editingContext=ERXEC.newEditingContext(objectStore=new EOObjectStoreCoordinator()) editingContext.lock() ... all the processing here, actually imports CSV, stores objects to editingContext and saves it ... } finally { editingContext.unlock() } } } ===
I hope there's no problem with that?
Thanks again, OC
|