Re: EC locking (headless and threads)
Re: EC locking (headless and threads)
- Subject: Re: EC locking (headless and threads)
- From: Kieran Kelleher <email@hidden>
- Date: Sun, 12 Feb 2012 09:10:24 -0500
Just to follow up..... you can use the task OSC pool as follows:
osc = ERXTaskObjectStoreCoordinatorPool.objectStoreCoordinator()
You can configure how many OSC's in the pool using this property which defaults to 1 (which is still better than using the default OSC for background EOF tasks):
er.extensions.concurrency.ERXTaskObjectStoreCoordinatorPool.maxCoordinators = 1
As a convenience, there is an abstract "task" class,ERXAbstractTask, you can subclass which has a newEditingContext() method that incorporates the OSC pool for you and adjusts EC timestamp to ensure fresh EOs in background tasks. IIRC, this is all explained in the WOWODc presentation too.
On Feb 11, 2012, at 6:00 PM, Kieran Kelleher wrote:
> Don't worry about the OSC unless you manipulating the OSC directly.
>
> BTW intensive background EOF activity can impact regular user EOF performance. One approach is to use a dedicated OSC pool for background tasks. Such a pool exists in Wonder. IIRC it is used in the WOWODC example app.
>
> Regards, Kieran.
> (Sent from my iPhone)
>
>
> On Feb 11, 2012, at 7:56 AM, Giles Palmer <email@hidden> wrote:
>
>> Hi
>>
>> Just to extend this... when (if at all) should we be locking the EOObjectStoreCoordinator as well, in the context of background threads?
>>
>> I lock and unlock my ec in a try, catch, finally, is that enough or do I also need to worry about the OSC?
>>
>> Thanks
>>
>>
>> Giles
>>
>>
>>> Also if you use ERXExecutorService to execute any Plain Old Java Callable (or Runnable), your editing contexts will be auto unlocked by safety-net unlocker at the end of execution if you haven't done so ....... however it is highly recommend that you follow the ec lock/try/finally/unlock pattern in in your Callable.call() or Runnable.run() methods anyway which will be better for long running tasks, recycling ec's if needed, etc. it doesn't hurt.
>>>
>>> EOEditingContext ec = ERXEC.newEditingContext();
>>> ec.lock();
>>> try {
>>> ........
>>> } finally {
>>> ec.unlock();
>>> }
>>>
>>> And yeah, do what Ramsey said .... save yourself time figuring out concurrency management of EC's, etc. by watching the WOWODC presentation from 2011. There is a bunch of stuff related to this in Wonder to make life in the background easy and totally painless for you and that WOWODC session explains it's usage.
>>>
>>>
>>> On Feb 10, 2012, at 11:34 AM, Ramsey Gurley wrote:
>>>
>>>> If you use ERXRunnable, then you still get autolocking. Just don't try to pass an existing EC or EOs to a background thread. Pass EOs by global id and create the EC on the thread.
>>>>
>>>> See also Kieran's most recent WOWODC presentation on ERXExecutor stuff and background thread processing.
>>>>
>>>> Ramsey
>>>>
>>>> On Feb 10, 2012, at 9:30 AM, Michael Gargano wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I just want to get clarification on something before I get myself into trouble later. If I have a headless WO app (or potential just a spawned worker thread), and I'm using ERXEC, I need to manually lock and unlock the context, correct? I'm assuming that ERXEC does the autolock/autounlock in the RR loop, which I won't have in this situation.
>>>>>
>>>>> Thanks.
>>>>> -Mike
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> _______________________________________________
>>> 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
>>
_______________________________________________
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