Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CADdasW4NCWrWHg=EGZuX8VZgJ9LH3zWmcxJ=S_VrU-SpuhHgNw@mail.gmail.com>
References: <CAK1mX7E1UNKuSV3MP_JyMxY+9j4A+Y3CL22MTz3YXDFnZZMs0w@mail.gmail.com>
 <CADdasW47EJhqXSkpvBgUH+aebzcfAg8f=sN7xzQZqM9VtoREfw@mail.gmail.com>
 <CAK1mX7FkcMi7cBhCxkqgViQguT3hd7nHYpgq3dayGacJ=y7vPA@mail.gmail.com>
 <CABDss3hv-n8u5Z6qqhE9fG+_KQ=zy-S0-9_5NpXJauLqJsEGeQ@mail.gmail.com>
 <CA+0=VoUL1=BX=Bn5d1r6S7rgtM1s32w3tQ-hv9Hw-Yeo_Mfr_w@mail.gmail.com>
 <CABDss3ipghNuBRv8Y_mXVT9b=ZArsH1xGRcA4VyAhieGGqJcOw@mail.gmail.com>
 <CA+0=VoUARcRnje8t1P0pS3FHzV21g9n_+sEeFEsD-unTmHKn6w@mail.gmail.com>
 <CABuYRcqyN6-NXpTu1NnAcs8=2D-bQBrftCFg0u4ejfSnbsTFXQ@mail.gmail.com> <CADdasW4NCWrWHg=EGZuX8VZgJ9LH3zWmcxJ=S_VrU-SpuhHgNw@mail.gmail.com>
From: Alexey Goncharuk <alexey.goncharuk@gmail.com>
Date: Mon, 20 Mar 2017 10:28:56 +0300
Message-ID: <CABDss3g99kXwn8-enHEUJMR3-woUMMCC9upB2bRTYdnRkHbGgA@mail.gmail.com>
Subject: Re: IgniteSemaphore and failoverSafe flag
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a11c11258ec550c054b247ad4
archived-at: Mon, 20 Mar 2017 07:29:10 -0000

--001a11c11258ec550c054b247ad4
Content-Type: text/plain; charset=UTF-8

I think re-creation should be handled by a user who will make sure that
nobody else is currently executing the guarded logic before the
re-creation. This is exactly the same semantics as with
BrokenBarrierException for j.u.c.CyclicBarrier.

2017-03-17 2:39 GMT+03:00 Vladisav Jelisavcic <vladisavj@gmail.com>:

> Hi everyone,
>
> I agree with Val, he's got a point; recreating the lock doesn't seem
> possible
> (at least not the with the transactional cache lock/semaphore we have).
> Is this re-create behavior really needed?
>
> Best regards,
> Vladisav
>
>
>
> On Thu, Mar 16, 2017 at 8:34 PM, Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Guys,
> >
> > How does recreation of the lock helps? My understanding is that scenario
> is
> > the following:
> >
> > 1. Client A creates and acquires a lock, and then starts to execute
> guarded
> > logic.
> > 2. Client B tries to acquire the same lock and parks to wait.
> > 3. Before client A unlocks, all affinity nodes for the lock fail, lock
> > disappears from the cache.
> > 4. Client B fails with exception, recreates the lock, acquires it, and
> > starts to execute guarded logic concurrently with client A.
> >
> > In my view this is wrong anyway, regardless of whether this happens
> > silently or with an exception handled in user's code. Because this code
> > doesn't have any way to know if client A still holds the lock or not.
> >
> > Am I missing something?
> >
> > -Val
> >
> > On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> > >
> > wrote:
> >
> > > On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk <
> > > alexey.goncharuk@gmail.com> wrote:
> > >
> > > > >
> > > > > Which user operation would result in exception? To my knowledge,
> user
> > > may
> > > > > already be holding the lock and not invoking any Ignite APIs, no?
> > > > >
> > > >
> > > > Yes, this is exactly my point.
> > > >
> > > > Imagine that a node already holds a lock and another node is waiting
> > for
> > > > the lock. If all partition nodes leave the grid and the lock is
> > > re-created,
> > > > this second node will immediately acquire the lock and we will have
> two
> > > > lock owners. I think in this case this second node (blocked on
> lock())
> > > > should get an exception saying that the lock was lost (which is, by
> the
> > > > way, the current behavior), and the first node should get an
> exception
> > on
> > > > unlock.
> > > >
> > >
> > > Makes sense.
> > >
> >
>

--001a11c11258ec550c054b247ad4--