ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Karachentsev <dkarachent...@gridgain.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Tue, 04 Apr 2017 09:05:40 GMT
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 <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
View raw message