[
https://issues.apache.org/jira/browse/IGNITE-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15296571#comment-15296571
]
Andrey Kornev commented on IGNITE-3164:
---------------------------------------
How about naming the flag {{withExcludeBackups()}}? This way the current
behavior will be preserved if the user doesn't specify the flag, thus making
the change backward compatible.
Having said that, I do not think this is a good approach in general: a flag
that only affects behavior of a single method - namely Cache.invoke() - is
applied to the entire IgniteCache interface.
An alternative approach might be as follows (just a suggestion):
- introduce an {{EntryProcessorInvokeOption}} enum with two values:
{{EXCLUDE_BACKUPS}}, {{INCLUDE_BACKUPS}}.
- allow users to optionally pass the enum as the first element of the
{{arguments}} parameter of the {{Cache.invoke()}} or {{Cache.invokeAll()}}
methods.
I believe such approach would achieve the same goal, but without polluting the
API.
Regards
Andrey
> Add an option to send resulting value instead of entry processor in
> transactional cache
> ---------------------------------------------------------------------------------------
>
> Key: IGNITE-3164
> URL: https://issues.apache.org/jira/browse/IGNITE-3164
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Affects Versions: 1.5.0.final
> Reporter: Valentin Kulichenko
> Assignee: Nikolay Tikhonov
> Labels: important
> Fix For: 1.7
>
>
> In some cases user can't guarantee that EP behaves consistently on all nodes.
> In transactional cache this can lead to inconsistent cache, because we invoke
> EP on both primary and backup nodes.
> We can add {{withSendValueToBackup()}} flag (naming is arguable) which will
> override current default behavior.
> We also need to update documentation, especially provide the explanation of
> EP behavior in atomic and transactional caches.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
