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);
>
> 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/kelleherk%40gmail.com
>
> This email sent to kelleh...@gmail.com
_______________________________________________
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
