One other important point
You should take great care to not end up with locks that cross each other.
I've run into huge problems when I try to synchronize sections of code that go
in and out of EOF. It's real easy to end up with:
thread 1:
synchronize (obj1) - success
ec.lock() - wait
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
Le 2010-09-03 à 10:56, Ken Anderson a écrit :
> 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?
Either way, just be sure that
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 unli
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
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
Le 2010-09-03 à 08:50, Kieran Kelleher a écrit :
> You need variation of usage #1
>
> editingContext().lock();
> try {
>
> // Do your stuff
>
> } finally {
> editingContext().unlock();
> }
Just in case editingContext() doesn't return the same editing context (« Do
your stuf
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.
>
>
A lot.
In usage 2, the editing context is not locked, and everything that goes along
with it. You're just using a java construct to provide exclusive use of the
editing context to your thread, but there are many other things that go along
with an editing context being locked that are not happe
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
10 matches
Mail list logo
