Hey Dmitry, sorry for the late reply, I'll try to bake a pr later during the day.
Best regards, Vladisav On Tue, Apr 4, 2017 at 11:05 AM, Dmitry Karachentsev < dkarachent...@gridgain.com> wrote: > Hi Vladislav, > > I see you're developing [1] for a while, did you have any chance to fix > it? If no, is there any estimate? > > [1] https://issues.apache.org/jira/browse/IGNITE-1977 > > Thanks! > > -Dmitry. > > > > 20.03.2017 10:28, Alexey Goncharuk пишет: > > 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. >>>>> >>>>> >
