[
https://issues.apache.org/jira/browse/IGNITE-11300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16767187#comment-16767187
]
Andrew Mashenkov commented on IGNITE-11300:
-------------------------------------------
[~Pavlukhin],
With allowOverwrite=true each entry will be updated within separate implicit
transaction and data streamer provides snapshot isolation guaranties only on
per-entry basis.
So, both policies looks safe as just skip operation on conflict as retry
operation. The first policy looks simpliest and performant and second one may
requires to resolve issues on unstable topologies (such as retry on recently
updated top ver) to prevent deadlocks.
With allowOverwrite=false we just put INITIAL entry version to the entry
versions list and it may be impossible to overwrite already invisible entry.
Assume, you have put entry into cache, then removed it and it wasn't cleaned
with Vacuum due to some reason (some active Tx is on fly),
and now you start DataStreamer with allowOverwrite=false that will try to
insert INITIAL version.
Will this change visible? Do we support this case correctly?
> MVCC: forbid using DataStreamer with allowOverwrite=true
> --------------------------------------------------------
>
> Key: IGNITE-11300
> URL: https://issues.apache.org/jira/browse/IGNITE-11300
> Project: Ignite
> Issue Type: Task
> Components: mvcc
> Affects Versions: 2.7
> Reporter: Ivan Pavlukhin
> Priority: Major
> Fix For: 2.8
>
>
> Calling {{IgniteDataStreamer.allowOverwrite(true)}} configures a streamer to
> use single-key cache put/remove operations for data modification. But
> put/remove operations on MVCC caches can be aborted due to write conflicts.
> So, some development effort is needed to support that mode properly. Let's
> throw exception in such case for MVCC caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
