augh .. i emailed from the wrong address. resent from @pobox.com:

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.

ms

On Sep 3, 2010, at 10:56 AM, Ken Anderson 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

Reply via email to