[ 
https://issues.apache.org/jira/browse/IGNITE-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yakov Zhdanov updated IGNITE-4665:
----------------------------------
    Description: 
Currently when we do cache updates in FULL_SYNC mode we update near readers 
(near cache entries) synchronously. This is quite big drawback in design, I 
think. I get each near reader update at cost of 1 extra backup update. I think 
everyone understands that partitioned cache easily turns to replicated once 
near readers number increases. In TX cache cost of such updates doubles.

I do not see any benefit on updating near entries in sync way. Outdated reads 
can still be possible if I don't read from primary or in TX context.

So, what I suggest:
1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as 
default).
2. Near entries are updated in async way
2.1 in atomic mode together with backup updates
2.2 in TX mode after tx is committed on primary. I would also suggest to 
exclude near readers from lock acquisition/release steps. Only force updates. 
Updates order will be ensured by single primary node and per-partition striping.
3. Near readers do not respond to primary. Once primary fails near readers get 
invalidated, if primary is alive then communication recovery ensures that 
message will be delivered to near.

Here is the discussion on dev list - 
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-0-Make-near-readers-update-async-by-default-tp14133.html

  was:
Currently when we do cache updates in FULL_SYNC mode we update near readers 
(near cache entries) synchronously. This is quite big drawback in design, I 
think. I get each near reader update at cost of 1 extra backup update. I think 
everyone understands that partitioned cache easily turns to replicated once 
near readers number increases. In TX cache cost of such updates doubles.

I do not see any benefit on updating near entries in sync way. Outdated reads 
can still be possible if I don't read from primary or in TX context.

So, what I suggest:
1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as 
default).
2. Near entries are updated in async way
2.1 in atomic mode together with backup updates
2.2 in TX mode after tx is committed on primary. I would also suggest to 
exclude near readers from lock acquisition/release steps. Only force updates. 
Updates order will be ensured by single primary node and per-partition striping.
3. Near readers do not respond to primary. Once primary fails near readers get 
invalidated, if primary is alive then communication recovery ensures that 
message will be delivered to near.


> Make near readers update async by default
> -----------------------------------------
>
>                 Key: IGNITE-4665
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4665
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Yakov Zhdanov
>            Priority: Minor
>             Fix For: 2.0
>
>
> Currently when we do cache updates in FULL_SYNC mode we update near readers 
> (near cache entries) synchronously. This is quite big drawback in design, I 
> think. I get each near reader update at cost of 1 extra backup update. I 
> think everyone understands that partitioned cache easily turns to replicated 
> once near readers number increases. In TX cache cost of such updates doubles.
> I do not see any benefit on updating near entries in sync way. Outdated reads 
> can still be possible if I don't read from primary or in TX context.
> So, what I suggest:
> 1. introduce CacheWriteSynchronizationMode.DHT_SYNC (leave PRIMARY_SYNC as 
> default).
> 2. Near entries are updated in async way
> 2.1 in atomic mode together with backup updates
> 2.2 in TX mode after tx is committed on primary. I would also suggest to 
> exclude near readers from lock acquisition/release steps. Only force updates. 
> Updates order will be ensured by single primary node and per-partition 
> striping.
> 3. Near readers do not respond to primary. Once primary fails near readers 
> get invalidated, if primary is alive then communication recovery ensures that 
> message will be delivered to near.
> Here is the discussion on dev list - 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-2-0-Make-near-readers-update-async-by-default-tp14133.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to