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 protected])
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com
>>>
>>> This email sent to [email protected]
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list ([email protected])
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>>
>> This email sent to [email protected]
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/lists%40cedarstone.co.uk
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
