:02 PM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] make Cluster Management Service CRUD operations thread
safe
Yes, the DLock machinery handles (has option) dlock grantor departure...
As I understand, right now we have dlock at config persistence layer, but this
does not guarantee
would end up with inconsistent state between what's persisted and what's
realized.
I believe the dlock can be configured to expire after a period of time.
From: Anthony Baker
Sent: Thursday, May 28, 2020 10:40 AM
To: dev@geode.apache.org
expire after a period of time.
From: Anthony Baker
Sent: Thursday, May 28, 2020 10:40 AM
To: dev@geode.apache.org
Subject: Re: [PROPOSAL] make Cluster Management Service CRUD operations thread
safe
I think the first question to answer is: can simultaneous updates to
reating a dlock. Is the the cost of creating a dlock per
> ID warrants the performance gain?
>
> Comment/Suggestions?
>
> Jinmei
>
> From: Jinmei Liao
> Sent: Tuesday, May 26, 2020 1:02 PM
> To: dev@geode.apache.org
> Subject: [PR
02 PM
To: dev@geode.apache.org
Subject: [PROPOSAL] make Cluster Management Service CRUD operations thread safe
Hi, Geode Community,
Currently, the CMS CRUD operations are not thread safe, if one call tries to
create a region, and another call tries to delete the same region, if timing is
of
Hi, Geode Community,
Currently, the CMS CRUD operations are not thread safe, if one call tries to
create a region, and another call tries to delete the same region, if timing is
off, we could end up with inconsistent state (what's in cluster config and
what's actually on the server). So we shou
