CacheWriteSynchronizationMode

["Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com>]

Hi Guys,

A new write sync mode

CacheWriteSynchronizationMode.LOCAL_SYNC

Would be very handy for us. Has this been brought up before? Any plan to implement it?

We are running in REPLICATED and we want the local node to be updated sync, but other nodes async. Using PRIMARY_SYNC doesn't quite work because the primary node for the key may not always be the local node. Or is there some other way to achieve this by ensuring that the local node is the primary?

Thanks,


This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252

Re: CacheWriteSynchronizationMode

[Andrey Mashenkov <an...@gmail.com>]

Hi Gordon,

Imagine you have nodes A,B,C and you try to update same key from A and B,
but A is primary for key.
While updating in progress node C has been gone.

What updates will be performed on A and B and in what order?

For now we get a lock on primary then backups, but how we will handle lock
issue in LOCAL_SYNC case to avoid deadlocks?


On Thu, Jun 1, 2017 at 4:01 AM, Gordon Reid (Nine Mile) <
gordon.reid@ninemilefinancial.com> wrote:

> Hi Guys,
>
>
>
> A new write sync mode
>
>
>
> CacheWriteSynchronizationMode.LOCAL_SYNC
>
>
>
> Would be very handy for us. Has this been brought up before? Any plan to
> implement it?
>
>
>
> We are running in REPLICATED and we want the local node to be updated
> sync, but other nodes async. Using PRIMARY_SYNC doesn’t quite work because
> the primary node for the key may not always be the local node. Or is there
> some other way to achieve this by ensuring that the local node is the
> primary?
>
>
>
> Thanks,
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>



-- 
Best regards,
Andrey V. Mashenkov

Re: CacheWriteSynchronizationMode

[Yakov Zhdanov <yz...@apache.org>]

Reid,

I don't think you can ensure that local node is primary for all updates. In
theory you can implement affinity function having only 1 primary node for
all partitions, but once you initiate replicated cache update from another
node then primary node becomes remote.

As far as LOCAL_SYNC - I am not sure that this option will be ever
introduced. In some scenarios it will be counter-intuitive.

Can you please provide more details on your usecase? Frequent updates to
replicated cache maybe very harmful for application from ops latency
standpoint.

--Yakov