: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
d 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
Subject: Re
ter 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
configur
I think the first question to answer is: can simultaneous updates to
configuration be made safely? Or what is the critical section of code that
needs to be protected?
Another thing to consider with dlocks is what happens in the failure case when
the lock is not properly released. Does it
The proposal is proposing using ONE single dlock to synchronize all CMS CRUD
operations, that means, in a given time, only one CRUD operation in CMS is
allowed in the entire cluster, this seems a bit too harsh.
Another way is to use a dlock per ID to only synchronize CRUD operation on the
same
