Hi Phillippe,
Short Story: I have not had a chance to get back to this - just been too busy - and I have been using my quick-fix anonymous subclass as shown in that patch for my abstract task superclass.
Long Story: That patch will not be implemented because it is not architecturally clean enough. I just need to get around to doing what Mike suggested in the comments on that JIRA - you can have a shot at that if you like and send me a git diff patch.
In any case, if you setCoalesceLocks and setAutoLock after instance creation, there is (or at least there was back in early 2010) a tiny risk in a highly concurrent busy app that the ec gets auto-locked (as a result of a notification for example) between the statement of creation and the statements where you disable locking. However, the use of ERXExecutorService will ensure that you have a ERXTaskThreadPoolExecutor in play which will in turn ensure that you will not get a deadlock since any locked ec will be unlocked at the end of the task (even after you do your own balanced lock/unlock)
The downside of this is that because of that tiny risk of autolock when your background ec was created, you have a case where you cannot call ec.dispose because if an autolock happened and you try to call ec.dispose you get an error. So if you want GC and ec.dispose'ing, you must create a manually locked instance from the start .... and we don't have API in Wonder for that right now yet.
Regards, Kieran
On Oct 17, 2011, at 6:49 PM, Philippe Rabier wrote: 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);
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|