Accessor region is probably a special case. Then can we add this caviar
then: "user can not create a region with the same name of a different type
except it's a proxy region"?

On Fri, Feb 2, 2018 at 11:17 AM, Sai Boorlagadda <sai.boorlaga...@gmail.com>
wrote:

> Agree with Dan. This is the only way I know that you can create accessor
> regions on peer members.
>
> On Fri, Feb 2, 2018 at 11:07 AM, Dan Smith <dsm...@pivotal.io> wrote:
>
>> Won't this break any use case were two members need to create the same
>> region with different attributes? For example someone might have some
>> members that are empty accessors of a replicated region:
>>
>> //Host data on members in group1
>> gfsh> create region --name=A --type=REPLICATE --group=group1
>>
>> //Group2 just needs access to data in region A
>> gfsh> create region --name=A --type=REPLICATE_PROXY --group=group2
>>
>> -Dan
>>
>> On Fri, Feb 2, 2018 at 10:19 AM, Jinmei Liao <jil...@pivotal.io> wrote:
>>
>>> Currently creating region with the same name on different groups are
>>> allowed by gfsh. Checks are done further on the servers when creating the
>>> region to see if the region attributes clashes with any existing region,
>>> and the operation will fail if types are different. Here is an example
>>> about this current behavior:
>>>
>>> gfsh> create region --name=A --type=REPLICATE --group=group1  // success
>>>
>>> gfsh> create region --name=A --type=REPLICATE --group=group2  // success
>>>
>>> gfsh> create region --name=A --type=PARTITION --group=group2
>>> --skip-if-exists  // skipping
>>>
>>> Member  | Status
>>>
>>> ------- | -----------------------------------------------
>>>
>>> server2 | Skipping "server2". Region "/A" already exists.
>>>
>>>
>>> gfsh>create region --name=A --type=PARTITION --group=group3
>>> --skip-if-exists // failure
>>>
>>> Member  | Status
>>>
>>> ------- | ------------------------------------------------------------
>>> ------------------------------------------------------------
>>> ---------------------------------------
>>>
>>> server3 | ERROR: Cannot create PartitionedRegion /A because another
>>> cache (10.118.33.243(server2:43156)<v4>:1026) has the same region
>>> defined as a non PartitionedRegion.
>>>
>>> We would like to propose catching the name clash earlier in gfsh for the
>>> last command as well. Since regions are referred to by names in the entire
>>> cluster (no server grouping considered at all), when trying to create a
>>> region, we should check for name clash in the entire cluster, not just in
>>> the specified server group. If we make this change, the behavior would be
>>> like this:
>>>
>>> gfsh> create region --name=A --type=REPLICATE --group=group1  // success
>>>
>>> gfsh> create region --name=A --type=REPLICATE --group=group2  // Error
>>>
>>> ERROR: Region "/A" already exists.
>>>
>>>
>>> gfsh> create region --name=A --type=REPLICATE --group=group2
>>> --skip-if-exists // skipping
>>>
>>> Skipping: Region "/A" already exists.
>>>
>>> gfsh> create region --name=A --type=PARTITION --group=group2
>>> --skip-if-exists
>>>
>>> Skipping. Region "/A" already exists.
>>>
>>> gfsh> create region --name=A --type=PARTITION --group=group3
>>> --skip-if-exists
>>> Skipping. Region "/A" already exists.
>>>
>>>
>>> Basically, the name clash check is on the entire cluster, not just on
>>> one specific server. This would lead to some change in script behavior, but
>>> keep the command simple and consistent.
>>>
>>> Any feedback is welcome.
>>>
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>>
>


-- 
Cheers

Jinmei

Reply via email to