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.kuliche...@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 <dsetrak...@apache.org > > > wrote: > > > On Tue, Mar 14, 2017 at 12:46 AM, Alexey Goncharuk < > > alexey.goncha...@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. > > >
