ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Thu, 16 Mar 2017 19:34:43 GMT

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
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?


On Tue, Mar 14, 2017 at 10:14 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>

> 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.

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