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 <kenli...@anderhome.com> 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 <kieran_li...@mac.com>
>>> 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 (Webobjects-dev@lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>>>>>
>>>>> This email sent to kieran_li...@mac.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/wolists%40gmail.com
>>>>
>>>> This email sent to woli...@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/kenlists%40anderhome.com
>>>
>>> This email sent to kenli...@anderhome.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/mschrag%40pobox.com
>>
>> This email sent to msch...@pobox.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
