+1 to avoid mixed tx-atomic cache groups. On the other side, doing atomic ops inside a tx have no relation to described reasons and is acceptable for me.
вт, 4 февр. 2020 г. в 14:40, Alexey Goncharuk <alexey.goncha...@gmail.com>: > I support this change. While this has no much difference on the storage > level, the protocols are indeed are very different and thus should be > separated. > > вт, 4 февр. 2020 г. в 14:36, Anton Vinogradov <a...@apache.org>: > > > Seems, we already started the separation by atomic operations restriction > > inside the transactions [1]. > > See no reason to allow mixes in this case. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-2313 > > > > On Tue, Feb 4, 2020 at 2:28 PM Ivan Rakov <ivan.glu...@gmail.com> wrote: > > > > > Igniters, > > > > > > Apparently it's possible in Ignite to configure a cache group with both > > > ATOMIC and TRANSACTIONAL caches. > > > Proof: IgniteCacheGroupsTest#testContinuousQueriesMultipleGroups* > tests. > > > In my opinion, it would be better to remove such possibility from the > > > product. There are several reasons: > > > > > > 1) The original idea of grouping caches was optimizing storage overhead > > and > > > PME time by joining data of similar caches into the same partitions. > > ATOMIC > > > and TRANSACTIONAL caches provide different guarantees and are designed > > for > > > different use cases, thus they can hardly be called "similar". > > > > > > 2) Diving deeper: synchronization protocols and possible reasons for > > > primary-backup divergences are conceptually different for ATOMIC and > > > TRANSACTIONAL cases. In TRANSACTIONAL case, transactions recovery > > protocol > > > allows to recover consistency if any participating node will fail, but > > for > > > ATOMIC caches there's possible scenario with failure of primary node > > where > > > neither of backups will contain the most recent state of the data. > > Example: > > > one backup have received updates 1, 3, 5 while another have received > 2, 4 > > > (which is possible due to message reordering), and even tracking > counters > > > [1] won't restore the consistency. The problem is that we can't > > distinguish > > > what kind of conflict we have faced in case update counters have > diverged > > > in a mixed group. > > > > > > 3) Mixed groups are poorly tested. I can't find any tests except a > couple > > > of smoke tests in IgniteCacheGroupsTest. We can't be sure that > different > > > synchronization protocols will work correctly for such configurations, > > > especially under load and with a variety of dependent configuration > > > parameters. > > > > > > 4) I have never heard of any feedback on mixed groups. I have asked > > > different people on this and no one recalled any attempts to configure > > such > > > groups. I believe that in fact no one has ever tried to do it. > > > > > > Please let me know if you are aware of any cases where mixed groups are > > > used or reasons to keep them. Otherwise I'll create a ticket to > prohibit > > > mixed configurations. > > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11797 > > > > > > -- > > > Best Regards, > > > Ivan Rakov > > > > > > -- Best regards, Alexei Scherbakov
