In the framework COScheduler (job scheduling), I expose an abstract method newEditingContext() to let the developer create his own ec with autolock = false (see discussion in february 2010) like this:
@Override
public EOEditingContext newEditingContext()
{
return COEditingContextFactory.newManualLockingEditingContext(new EOObjectStoreCoordinator());
}
After seeing your presentation at the WOWODC'11, I was plenty of hope because I discover the class ERXTaskObjectStoreCoordinatorPool which is great. So I decided to remove this method to simplify the use of the framework and use the obs pool. However, I see the pb remains in the class ERXAbstractTask when I read the javadoc:
/**
* <strong>You must manually lock and unlock the editing context returned by
* this method.<strong> It is not recommended that you depend on auto
* locking in background threads.
*
* Even though this method currently returns an auto-locking EC if
* auto-locking is turned on for the app, a future update is planned that
* will return a manually locking EC from this method even if auto-locking
* is turned on for regular ECs used in normal request-response execution.
*
* @return a new EOEditingContext.
*/
protected EOEditingContext newEditingContext()
IMH, we can't set this kind of setting at the application level because it's "dangerous": we can mix background threads and UI in the same app.
Regarding the framework I'm working on, I see 2 options:
- set the abstract method newEditingContext() and let the user/developer create its own method like that:
EOObjectStoreCoordinator osc = ERXTaskObjectStoreCoordinatorPool.objectStoreCoordinator();
ERXEC ec = (ERXEC) MyECFactory.newManualLockingEditingContext(osc);
or provide a newEditingContext() method like you but I would add:
EOObjectStoreCoordinator osc = ERXTaskObjectStoreCoordinatorPool.objectStoreCoordinator();
ERXEC ec = (ERXEC) ERXEC.newEditingContext(osc);;
ec.setCoalesceAutoLocks(false);
ec.setUseAutoLock(false);
I don't like very much the 2 options even if the first one can guarantee a good working.
Sorry to be so long but do you have an update about the ticket below?
Philippe
On 19 févr. 2010, at 20:07, Kieran Kelleher wrote: