ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladisav Jelisavcic <vladis...@gmail.com>
Subject Re: IgniteSemaphore and failoverSafe flag
Date Thu, 06 Apr 2017 13:27:00 GMT
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 <
dkarachentsev@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message