ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Mon, 20 Mar 2017 07:28:56 GMT
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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message