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 continue to block all management 
/configuration operations?  Does it expire after a period of time?

Anthony


> On May 28, 2020, at 10:17 AM, Jinmei Liao <jil...@vmware.com> wrote:
> 
> 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 ID element. That way, we allow more concurrency. I am just not sure 
> what's the cost of creating a dlock. Is the the cost of creating a dlock per 
> ID warrants the performance gain?
> 
> Comment/Suggestions?
> 
> Jinmei
> ________________________________
> From: Jinmei Liao <jil...@vmware.com>
> Sent: Tuesday, May 26, 2020 1:02 PM
> To: dev@geode.apache.org <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 off, we could end up with inconsistent state (what's in cluster config and 
> what's actually on the server). So we should make these operations thread 
> safe. Here is the proposal to try to achieve it:
> 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FMake%2BCluster%2BManagement%2BService%2528CMS%2529%2BThread%2BSafe&amp;data=02%7C01%7Cbakera%40vmware.com%7C08663df2f1c846dddaaf08d8032d9d8f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637262841746056995&amp;sdata=eayoO7sOyyFgSsOP%2FXiN2U1L5YTbbukmBVkVmXtR3jI%3D&amp;reserved=0
> 
> Comments/suggestions welcome.
> 
> Jinmei

Reply via email to