ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: Forbid mixed cache groups with both atomic and transactional caches
Date Wed, 05 Feb 2020 10:20:06 GMT
Ivan.

It seems we don’t have a format definition for a «community decision»
We, for sure, should fill this gap.

Me and Andrey Gura, have certain proposals for our development process based on metrics API
discussion.

We will share those proposals after 2.8 release and some additional discussion.


> 5 февр. 2020 г., в 13:11, Ivan Pavlukhin <vololo100@gmail.com> написал(а):
> 
> Folks,
> 
> A bit of offtop. Do we have some recommendations in the community how
> long should we wait until treating something as "a Community
> conclusion"? It worries me a little bit that I see a discussion for a
> first time and there is already a conclusion. And the discussion was
> started lesser than 24 hours ago. I suppose we should allow everyone
> interested to share an opinion (here I agree with the proposal) and it
> usually requires some time in open-source communities.
> 
> ср, 5 февр. 2020 г. в 10:58, Ivan Rakov <ivan.glukos@gmail.com>:
>> 
>> Folks,
>> 
>> Thanks for your feedback.
>> I've created a JIRA issue on this change:
>> https://issues.apache.org/jira/browse/IGNITE-12622
>> 
>> On Tue, Feb 4, 2020 at 10:43 PM Denis Magda <dmagda@apache.org> wrote:
>> 
>>> +1 from my end. It doesn't sound like a big deal if Ignite users need to
>>> define separate groups for atomic and transactional caches.
>>> 
>>> -
>>> Denis
>>> 
>>> 
>>> On Tue, Feb 4, 2020 at 3:28 AM 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,
> Ivan Pavlukhin


Mime
View raw message