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