[
https://issues.apache.org/jira/browse/IGNITE-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15231766#comment-15231766
]
Semen Boikov commented on IGNITE-2645:
--------------------------------------
Hi Artem,
Reviewed, looks good (I did few minor changes, please take a look).
Alexey had this comment: 'If read-through happened on innerGet(), but entry
processor did not change the value, we still need to propagate the updated
value to backups.' This is not implemented, please discuss with him what will
go wrong if we do not pass value on backup. What the difference if we do simple
'get' on primary? Also we do not send value to backup if for example
read-through happened for 'putIfAbsent'.
> Assertion error in ATOMIC cachce for invokeAll and cache store
> --------------------------------------------------------------
>
> Key: IGNITE-2645
> URL: https://issues.apache.org/jira/browse/IGNITE-2645
> Project: Ignite
> Issue Type: Bug
> Components: cache
> Affects Versions: ignite-1.4
> Reporter: Alexey Goncharuk
> Assignee: Artem Shutak
> Labels: community
> Fix For: 1.6
>
> Attachments: EntryProcessorFails.java
>
>
> Assertion happens under the following conditions:
> * Cache is empty
> * Cache store contains non-null values for some keys
> * invokeAll is invoked for those keys
> Update version is generated when update request reaches the primary node.
> Then, we need to read-through stored values (the cache is empty) and pass
> them to transformers. Since read-through changes entry version, subsequent
> update fails with an assertion because read-through version is generated
> later than update version.
> The scenario when a read-through is implemented via a separate loop with
> innerGet() is possible only with invokeAll() because this is the only
> multi-key cache operation that requires the previous entry value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
