ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Forbid mixed cache groups with both atomic and transactional caches
Date Tue, 04 Feb 2020 11:48:23 GMT
+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.goncharuk@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 <av@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.glukos@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message