concurrent access on the same key - need precision

[Olivier Mallassi <ol...@gmail.com>]

hi all

I have a question internally here and I would need your help.
We will face a case where a given key (from a PARTITION_REDUDANT region)
will be updated (at regular pace, like 250 ms) but *will be massively and
concurrently read by a lot of processes* (100+).

I was wondering if it could be an issue in terms of locking or others.
Moreoever, I cannot remember if the get are load-balanced on the replicas
(in that case it helps) or are routed to the primary partition (like put).

any clarification would be helpful.

Thanks a lot.

Re: concurrent access on the same key - need precision

[Olivier Mallassi <ol...@gmail.com>]

clear.
thx.

On Wed, Mar 29, 2017 at 10:01 PM, Michael Stolz <ms...@pivotal.io> wrote:

> Gets are load-balanced across the redundant copies UNLESS they are
> operating within the context of a Transaction, in which case they will
> always hit the local server on which the transaction is being managed.
> Puts are replicated synchronously and while the primary is locked to limit
> the chance of a stale get.
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Wed, Mar 29, 2017 at 11:00 AM, Olivier Mallassi <
> olivier.mallassi@gmail.com> wrote:
>
>> hi all
>>
>> I have a question internally here and I would need your help.
>> We will face a case where a given key (from a PARTITION_REDUDANT region)
>> will be updated (at regular pace, like 250 ms) but *will be massively and
>> concurrently read by a lot of processes* (100+).
>>
>> I was wondering if it could be an issue in terms of locking or others.
>> Moreoever, I cannot remember if the get are load-balanced on the replicas
>> (in that case it helps) or are routed to the primary partition (like put).
>>
>> any clarification would be helpful.
>>
>> Thanks a lot.
>>
>
>

Re: concurrent access on the same key - need precision

[Michael Stolz <ms...@pivotal.io>]

Gets are load-balanced across the redundant copies UNLESS they are
operating within the context of a Transaction, in which case they will
always hit the local server on which the transaction is being managed.
Puts are replicated synchronously and while the primary is locked to limit
the chance of a stale get.



--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Mar 29, 2017 at 11:00 AM, Olivier Mallassi <
olivier.mallassi@gmail.com> wrote:

> hi all
>
> I have a question internally here and I would need your help.
> We will face a case where a given key (from a PARTITION_REDUDANT region)
> will be updated (at regular pace, like 250 ms) but *will be massively and
> concurrently read by a lot of processes* (100+).
>
> I was wondering if it could be an issue in terms of locking or others.
> Moreoever, I cannot remember if the get are load-balanced on the replicas
> (in that case it helps) or are routed to the primary partition (like put).
>
> any clarification would be helpful.
>
> Thanks a lot.
>