Re: Synchronized Editing Context for Locking/Unlocking
Re: Synchronized Editing Context for Locking/Unlocking
- Subject: Re: Synchronized Editing Context for Locking/Unlocking
- From: Ken Anderson <email@hidden>
- Date: Fri, 3 Sep 2010 11:09:54 -0400
Ah yes - knew there was a good reason I was doing it that way :)
Ken
On Sep 3, 2010, at 11:05 AM, Michael Schrag wrote:
> Lock outside is objectively right ... If lock throws an exception and you're inside the try, you will unlock when you didn't have a lock in the first place. Highly unlikely, but good form to maintain.
>
> Sent from my iPad
>
> On Sep 3, 2010, at 10:56 AM, Ken Anderson <email@hidden> wrote:
>
>> I emailed Kieran the same question directly.... I lock prior to the try block personally.
>>
>> To me, it's stylistic, since it's going to block in any case. Maybe someone on the list has a different perspective?
>>
>> On Sep 3, 2010, at 10:54 AM, John Bruce wrote:
>>
>>> Hi Kieran,
>>>
>>> Just wondering - what is the difference between having the lock inside
>>> the try versus outside? Is it just to ensure that it is locked before
>>> doing anything with the context? I've always locked inside the try
>>> block as the first statement but I notice others lock outside the try.
>>> I always assumed this was a style preference but is there a technical
>>> reason to lock outside.
>>>
>>> Cheers,
>>>
>>> John
>>>
>>>
>>> On Fri, Sep 3, 2010 at 1:50 PM, Kieran Kelleher <email@hidden> wrote:
>>>> You need variation of usage #1
>>>>
>>>> editingContext().lock();
>>>> try {
>>>>
>>>> // Do your stuff
>>>>
>>>> } finally {
>>>> editingContext().unlock();
>>>> }
>>>>
>>>>
>>>>
>>>> On Sep 3, 2010, at 7:59 AM, Farrukh Ijaz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> What is the difference between the two? I noticed both work almost the same way.
>>>>>
>>>>> Usage 1:
>>>>>
>>>>> try {
>>>>> editingContext().lock();
>>>>> // Do your stuff
>>>>> } finally {
>>>>> editingContext().unlock();
>>>>> }
>>>>>
>>>>> Usage 2:
>>>>>
>>>>> synchronized(editingContext()) {
>>>>> // Do your stuff
>>>>> }
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Farrukh _______________________________________________
>>>>> 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
_______________________________________________
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