The question is mainly for Kieran.
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:
> http://issues.objectstyle.org/jira/browse/WONDER-478
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
