Mark MVCC with @IgniteExperimental

[Nikolay Izhikov-2]

Hello, Igniters.

Should we mark MVCC feature with the new @IgniteExperimental?

We explicitly note users that MVCC has beta status, for now [1]

> Beta version of Transactional SQL and MVCC
> In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to allow users to experiment and share feedback.
> This version of Transactional SQL and MVCC should not be considered for production.


[1] https://apacheignite.readme.io/docs/multiversion-concurrency-control

[sdarlington]

Yes! I’ve already seen people try to use this without awareness that it’s not production ready.

What happens with the annotation, incidentally? Is it just in the documentation or do you get a compile-time warning?

> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
>
> Hello, Igniters.
>
> Should we mark MVCC feature with the new @IgniteExperimental?
>
> We explicitly note users that MVCC has beta status, for now [1]
>
>> Beta version of Transactional SQL and MVCC
>> In Ignite v2.7, Transactional SQL and MVCC are released as beta versions to allow users to experiment and share feedback.
>> This version of Transactional SQL and MVCC should not be considered for production.
>
>
> [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
>
>

[slava.koptilin]

Hello,

I think the right answer is YES. It should be marked with the new
annotation @IgniteExperimental.

Thanks,
S.

чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
[hidden email]>:

> Yes! I’ve already seen people try to use this without awareness that it’s
> not production ready.
>
> What happens with the annotation, incidentally? Is it just in the
> documentation or do you get a compile-time warning?
>
> > On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> >
> > Hello, Igniters.
> >
> > Should we mark MVCC feature with the new @IgniteExperimental?
> >
> > We explicitly note users that MVCC has beta status, for now [1]
> >
> >> Beta version of Transactional SQL and MVCC
> >> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> versions to allow users to experiment and share feedback.
> >> This version of Transactional SQL and MVCC should not be considered for
> production.
> >
> >
> > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
> >
> >
>
>
>

[Alexey Goncharuk]

Agree, let's mark MVCC experimental.

Stephen, the annotation serves as an additional documentation-style marker.
For now there are no compile-time warnings when the API is used.

чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
[hidden email]>:

> Yes! I’ve already seen people try to use this without awareness that it’s
> not production ready.
>
> What happens with the annotation, incidentally? Is it just in the
> documentation or do you get a compile-time warning?
>
> > On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> >
> > Hello, Igniters.
> >
> > Should we mark MVCC feature with the new @IgniteExperimental?
> >
> > We explicitly note users that MVCC has beta status, for now [1]
> >
> >> Beta version of Transactional SQL and MVCC
> >> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> versions to allow users to experiment and share feedback.
> >> This version of Transactional SQL and MVCC should not be considered for
> production.
> >
> >
> > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
> >
> >
>
>
>

[agura]

+1

By the way, is there any reason to have this code in the master
branch? It seems feature is in unsupportable state and just wastes TC
time and our effort to support MVCC related tests.

On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
<[hidden email]> wrote:

>
> Agree, let's mark MVCC experimental.
>
> Stephen, the annotation serves as an additional documentation-style marker.
> For now there are no compile-time warnings when the API is used.
>
> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> [hidden email]>:
>
> > Yes! I’ve already seen people try to use this without awareness that it’s
> > not production ready.
> >
> > What happens with the annotation, incidentally? Is it just in the
> > documentation or do you get a compile-time warning?
> >
> > > On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> > >
> > > Hello, Igniters.
> > >
> > > Should we mark MVCC feature with the new @IgniteExperimental?
> > >
> > > We explicitly note users that MVCC has beta status, for now [1]
> > >
> > >> Beta version of Transactional SQL and MVCC
> > >> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > versions to allow users to experiment and share feedback.
> > >> This version of Transactional SQL and MVCC should not be considered for
> > production.
> > >
> > >
> > > [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > >
> > >
> >
> >
> >

[Nikolay Izhikov-2]

> By the way, is there any reason to have this code in the master branch

I support removal MVCC from master.

> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]> написал(а):
>
> +1
>
> By the way, is there any reason to have this code in the master
> branch? It seems feature is in unsupportable state and just wastes TC
> time and our effort to support MVCC related tests.
>
> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> <[hidden email]> wrote:
>>
>> Agree, let's mark MVCC experimental.
>>
>> Stephen, the annotation serves as an additional documentation-style marker.
>> For now there are no compile-time warnings when the API is used.
>>
>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
>> [hidden email]>:
>>
>>> Yes! I’ve already seen people try to use this without awareness that it’s
>>> not production ready.
>>>
>>> What happens with the annotation, incidentally? Is it just in the
>>> documentation or do you get a compile-time warning?
>>>
>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
>>>>
>>>> Hello, Igniters.
>>>>
>>>> Should we mark MVCC feature with the new @IgniteExperimental?
>>>>
>>>> We explicitly note users that MVCC has beta status, for now [1]
>>>>
>>>>> Beta version of Transactional SQL and MVCC
>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
>>> versions to allow users to experiment and share feedback.
>>>>> This version of Transactional SQL and MVCC should not be considered for
>>> production.
>>>>
>>>>
>>>> [1] https://apacheignite.readme.io/docs/multiversion-concurrency-control
>>>>
>>>>
>>>
>>>
>>>

[Ilya Kasnacheev]

Hello!

Why would we drop MVCC!?

I can totally imagine a scenario where a large Ignite user surfaces with
fixes for MVCC mode, if it is kept as an experimental feature. Then maybe
it will graduate to beta some time in future.

If it does too much strain on the TC, let's discuss that, but I don't
remember problems with TC load lately, so maybe this is a moot point.

Regards,
--
Ilya Kasnacheev


чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:

> > By the way, is there any reason to have this code in the master branch
>
> I support removal MVCC from master.
>
>
> > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]> написал(а):
> >
> > +1
> >
> > By the way, is there any reason to have this code in the master
> > branch? It seems feature is in unsupportable state and just wastes TC
> > time and our effort to support MVCC related tests.
> >
> > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > <[hidden email]> wrote:
> >>
> >> Agree, let's mark MVCC experimental.
> >>
> >> Stephen, the annotation serves as an additional documentation-style
> marker.
> >> For now there are no compile-time warnings when the API is used.
> >>
> >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> >> [hidden email]>:
> >>
> >>> Yes! I’ve already seen people try to use this without awareness that
> it’s
> >>> not production ready.
> >>>
> >>> What happens with the annotation, incidentally? Is it just in the
> >>> documentation or do you get a compile-time warning?
> >>>
> >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> >>>>
> >>>> Hello, Igniters.
> >>>>
> >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> >>>>
> >>>> We explicitly note users that MVCC has beta status, for now [1]
> >>>>
> >>>>> Beta version of Transactional SQL and MVCC
> >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> >>> versions to allow users to experiment and share feedback.
> >>>>> This version of Transactional SQL and MVCC should not be considered
> for
> >>> production.
> >>>>
> >>>>
> >>>> [1]
> https://apacheignite.readme.io/docs/multiversion-concurrency-control
> >>>>
> >>>>
> >>>
> >>>
> >>>
>
>

[Maxim Muzafarov]

Ilya,


1. MVCC support requires code maintenance for other developed features
even if has not used and disabled. Currently, we've got an x2 level of
difficulty for implementation of new features.

2. It would be much easy to develop and support clusters with
mvcc-caches only rather than have a mixed configuration. With this
option we can dramatically reduce the amount of codebase removing from
mvcc-branch local, atomic, tx caches.


So, I'm +1 to remove it from the master branch and mark the current
API with @IgniteExperimental.

On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]> wrote:

>
> Hello!
>
> Why would we drop MVCC!?
>
> I can totally imagine a scenario where a large Ignite user surfaces with
> fixes for MVCC mode, if it is kept as an experimental feature. Then maybe
> it will graduate to beta some time in future.
>
> If it does too much strain on the TC, let's discuss that, but I don't
> remember problems with TC load lately, so maybe this is a moot point.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
>
> > > By the way, is there any reason to have this code in the master branch
> >
> > I support removal MVCC from master.
> >
> >
> > > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]> написал(а):
> > >
> > > +1
> > >
> > > By the way, is there any reason to have this code in the master
> > > branch? It seems feature is in unsupportable state and just wastes TC
> > > time and our effort to support MVCC related tests.
> > >
> > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > > <[hidden email]> wrote:
> > >>
> > >> Agree, let's mark MVCC experimental.
> > >>
> > >> Stephen, the annotation serves as an additional documentation-style
> > marker.
> > >> For now there are no compile-time warnings when the API is used.
> > >>
> > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > >> [hidden email]>:
> > >>
> > >>> Yes! I’ve already seen people try to use this without awareness that
> > it’s
> > >>> not production ready.
> > >>>
> > >>> What happens with the annotation, incidentally? Is it just in the
> > >>> documentation or do you get a compile-time warning?
> > >>>
> > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> > >>>>
> > >>>> Hello, Igniters.
> > >>>>
> > >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > >>>>
> > >>>> We explicitly note users that MVCC has beta status, for now [1]
> > >>>>
> > >>>>> Beta version of Transactional SQL and MVCC
> > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > >>> versions to allow users to experiment and share feedback.
> > >>>>> This version of Transactional SQL and MVCC should not be considered
> > for
> > >>> production.
> > >>>>
> > >>>>
> > >>>> [1]
> > https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> >
> >

[Ilya Kasnacheev]

Hello!

Please keep in mind that you need to create a separate proposal voting
thread if you really like it to count. I wonder if Dmitry Pavlov can help
us with the procedure.

Otherwise, I think it makes total sense to restrict MVCC clusters to only
have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in
our current implementation) and no ATOMIC caches at all.

Regards,
--
Ilya Kasnacheev


чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:

> Ilya,
>
>
> 1. MVCC support requires code maintenance for other developed features
> even if has not used and disabled. Currently, we've got an x2 level of
> difficulty for implementation of new features.
>
> 2. It would be much easy to develop and support clusters with
> mvcc-caches only rather than have a mixed configuration. With this
> option we can dramatically reduce the amount of codebase removing from
> mvcc-branch local, atomic, tx caches.
>
>
> So, I'm +1 to remove it from the master branch and mark the current
> API with @IgniteExperimental.
>
> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]>
> wrote:
> >
> > Hello!
> >
> > Why would we drop MVCC!?
> >
> > I can totally imagine a scenario where a large Ignite user surfaces with
> > fixes for MVCC mode, if it is kept as an experimental feature. Then maybe
> > it will graduate to beta some time in future.
> >
> > If it does too much strain on the TC, let's discuss that, but I don't
> > remember problems with TC load lately, so maybe this is a moot point.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> >
> > > > By the way, is there any reason to have this code in the master
> branch
> > >
> > > I support removal MVCC from master.
> > >
> > >
> > > > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]> написал(а):
> > > >
> > > > +1
> > > >
> > > > By the way, is there any reason to have this code in the master
> > > > branch? It seems feature is in unsupportable state and just wastes TC
> > > > time and our effort to support MVCC related tests.
> > > >
> > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > > > <[hidden email]> wrote:
> > > >>
> > > >> Agree, let's mark MVCC experimental.
> > > >>
> > > >> Stephen, the annotation serves as an additional documentation-style
> > > marker.
> > > >> For now there are no compile-time warnings when the API is used.
> > > >>
> > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > > >> [hidden email]>:
> > > >>
> > > >>> Yes! I’ve already seen people try to use this without awareness
> that
> > > it’s
> > > >>> not production ready.
> > > >>>
> > > >>> What happens with the annotation, incidentally? Is it just in the
> > > >>> documentation or do you get a compile-time warning?
> > > >>>
> > > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> wrote:
> > > >>>>
> > > >>>> Hello, Igniters.
> > > >>>>
> > > >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > > >>>>
> > > >>>> We explicitly note users that MVCC has beta status, for now [1]
> > > >>>>
> > > >>>>> Beta version of Transactional SQL and MVCC
> > > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > > >>> versions to allow users to experiment and share feedback.
> > > >>>>> This version of Transactional SQL and MVCC should not be
> considered
> > > for
> > > >>> production.
> > > >>>>
> > > >>>>
> > > >>>> [1]
> > > https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > >
> > >
>

[Alexei Scherbakov]

I'm strongly support removal of MVCC from master.

At the current state it bloats code base and should be reworked from
scratch using separate code base.

чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <[hidden email]>:

> Hello!
>
> Please keep in mind that you need to create a separate proposal voting
> thread if you really like it to count. I wonder if Dmitry Pavlov can help
> us with the procedure.
>
> Otherwise, I think it makes total sense to restrict MVCC clusters to only
> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in
> our current implementation) and no ATOMIC caches at all.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
>
> > Ilya,
> >
> >
> > 1. MVCC support requires code maintenance for other developed features
> > even if has not used and disabled. Currently, we've got an x2 level of
> > difficulty for implementation of new features.
> >
> > 2. It would be much easy to develop and support clusters with
> > mvcc-caches only rather than have a mixed configuration. With this
> > option we can dramatically reduce the amount of codebase removing from
> > mvcc-branch local, atomic, tx caches.
> >
> >
> > So, I'm +1 to remove it from the master branch and mark the current
> > API with @IgniteExperimental.
> >
> > On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]>
> > wrote:
> > >
> > > Hello!
> > >
> > > Why would we drop MVCC!?
> > >
> > > I can totally imagine a scenario where a large Ignite user surfaces
> with
> > > fixes for MVCC mode, if it is kept as an experimental feature. Then
> maybe
> > > it will graduate to beta some time in future.
> > >
> > > If it does too much strain on the TC, let's discuss that, but I don't
> > > remember problems with TC load lately, so maybe this is a moot point.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> > >
> > > > > By the way, is there any reason to have this code in the master
> > branch
> > > >
> > > > I support removal MVCC from master.
> > > >
> > > >
> > > > > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> написал(а):
> > > > >
> > > > > +1
> > > > >
> > > > > By the way, is there any reason to have this code in the master
> > > > > branch? It seems feature is in unsupportable state and just wastes
> TC
> > > > > time and our effort to support MVCC related tests.
> > > > >
> > > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > > > > <[hidden email]> wrote:
> > > > >>
> > > > >> Agree, let's mark MVCC experimental.
> > > > >>
> > > > >> Stephen, the annotation serves as an additional
> documentation-style
> > > > marker.
> > > > >> For now there are no compile-time warnings when the API is used.
> > > > >>
> > > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > > > >> [hidden email]>:
> > > > >>
> > > > >>> Yes! I’ve already seen people try to use this without awareness
> > that
> > > > it’s
> > > > >>> not production ready.
> > > > >>>
> > > > >>> What happens with the annotation, incidentally? Is it just in the
> > > > >>> documentation or do you get a compile-time warning?
> > > > >>>
> > > > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> > wrote:
> > > > >>>>
> > > > >>>> Hello, Igniters.
> > > > >>>>
> > > > >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > > > >>>>
> > > > >>>> We explicitly note users that MVCC has beta status, for now [1]
> > > > >>>>
> > > > >>>>> Beta version of Transactional SQL and MVCC
> > > > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > > > >>> versions to allow users to experiment and share feedback.
> > > > >>>>> This version of Transactional SQL and MVCC should not be
> > considered
> > > > for
> > > > >>> production.
> > > > >>>>
> > > > >>>>
> > > > >>>> [1]
> > > > https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > >
> > > >
> >
>

--

Best regards,
Alexei Scherbakov

[agura]

Folks,

Do not read between lines please. I didn't suggest MVCC removal. I
asked, literally: is there any reason to have this code in the master?
branch?

Instead of listing reasons why we should support it I see posts like
remove it from branch.

Please, do not distort the meaning of the question.

I agree with Ilya. Code change like this requires additional vote and
I believe this vote will not pass with solution "remove it".

On Thu, Feb 6, 2020 at 9:25 PM Alexei Scherbakov
<[hidden email]> wrote:

>
> I'm strongly support removal of MVCC from master.
>
> At the current state it bloats code base and should be reworked from
> scratch using separate code base.
>
> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <[hidden email]>:
>
> > Hello!
> >
> > Please keep in mind that you need to create a separate proposal voting
> > thread if you really like it to count. I wonder if Dmitry Pavlov can help
> > us with the procedure.
> >
> > Otherwise, I think it makes total sense to restrict MVCC clusters to only
> > have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in
> > our current implementation) and no ATOMIC caches at all.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
> >
> > > Ilya,
> > >
> > >
> > > 1. MVCC support requires code maintenance for other developed features
> > > even if has not used and disabled. Currently, we've got an x2 level of
> > > difficulty for implementation of new features.
> > >
> > > 2. It would be much easy to develop and support clusters with
> > > mvcc-caches only rather than have a mixed configuration. With this
> > > option we can dramatically reduce the amount of codebase removing from
> > > mvcc-branch local, atomic, tx caches.
> > >
> > >
> > > So, I'm +1 to remove it from the master branch and mark the current
> > > API with @IgniteExperimental.
> > >
> > > On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]>
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > Why would we drop MVCC!?
> > > >
> > > > I can totally imagine a scenario where a large Ignite user surfaces
> > with
> > > > fixes for MVCC mode, if it is kept as an experimental feature. Then
> > maybe
> > > > it will graduate to beta some time in future.
> > > >
> > > > If it does too much strain on the TC, let's discuss that, but I don't
> > > > remember problems with TC load lately, so maybe this is a moot point.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> > > >
> > > > > > By the way, is there any reason to have this code in the master
> > > branch
> > > > >
> > > > > I support removal MVCC from master.
> > > > >
> > > > >
> > > > > > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> > написал(а):
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > By the way, is there any reason to have this code in the master
> > > > > > branch? It seems feature is in unsupportable state and just wastes
> > TC
> > > > > > time and our effort to support MVCC related tests.
> > > > > >
> > > > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > > > > > <[hidden email]> wrote:
> > > > > >>
> > > > > >> Agree, let's mark MVCC experimental.
> > > > > >>
> > > > > >> Stephen, the annotation serves as an additional
> > documentation-style
> > > > > marker.
> > > > > >> For now there are no compile-time warnings when the API is used.
> > > > > >>
> > > > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > > > > >> [hidden email]>:
> > > > > >>
> > > > > >>> Yes! I’ve already seen people try to use this without awareness
> > > that
> > > > > it’s
> > > > > >>> not production ready.
> > > > > >>>
> > > > > >>> What happens with the annotation, incidentally? Is it just in the
> > > > > >>> documentation or do you get a compile-time warning?
> > > > > >>>
> > > > > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> > > wrote:
> > > > > >>>>
> > > > > >>>> Hello, Igniters.
> > > > > >>>>
> > > > > >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > > > > >>>>
> > > > > >>>> We explicitly note users that MVCC has beta status, for now [1]
> > > > > >>>>
> > > > > >>>>> Beta version of Transactional SQL and MVCC
> > > > > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > > > > >>> versions to allow users to experiment and share feedback.
> > > > > >>>>> This version of Transactional SQL and MVCC should not be
> > > considered
> > > > > for
> > > > > >>> production.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> [1]
> > > > > https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > > > > >>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > >
> > > > >
> > >
> >
>
>
> --
>
> Best regards,
> Alexei Scherbakov

[agura]

> 1. MVCC support requires code maintenance for other developed features
> even if has not used and disabled. Currently, we've got an x2 level of
> difficulty for implementation of new features.

Maxim,

I believe that not all features requires x2 level of implementation
difficulty. Could you list here features which stumbled upon the MVCC?

On Thu, Feb 6, 2020 at 7:41 PM Maxim Muzafarov <[hidden email]> wrote:

>
> Ilya,
>
>
> 1. MVCC support requires code maintenance for other developed features
> even if has not used and disabled. Currently, we've got an x2 level of
> difficulty for implementation of new features.
>
> 2. It would be much easy to develop and support clusters with
> mvcc-caches only rather than have a mixed configuration. With this
> option we can dramatically reduce the amount of codebase removing from
> mvcc-branch local, atomic, tx caches.
>
>
> So, I'm +1 to remove it from the master branch and mark the current
> API with @IgniteExperimental.
>
> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]> wrote:
> >
> > Hello!
> >
> > Why would we drop MVCC!?
> >
> > I can totally imagine a scenario where a large Ignite user surfaces with
> > fixes for MVCC mode, if it is kept as an experimental feature. Then maybe
> > it will graduate to beta some time in future.
> >
> > If it does too much strain on the TC, let's discuss that, but I don't
> > remember problems with TC load lately, so maybe this is a moot point.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> >
> > > > By the way, is there any reason to have this code in the master branch
> > >
> > > I support removal MVCC from master.
> > >
> > >
> > > > 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]> написал(а):
> > > >
> > > > +1
> > > >
> > > > By the way, is there any reason to have this code in the master
> > > > branch? It seems feature is in unsupportable state and just wastes TC
> > > > time and our effort to support MVCC related tests.
> > > >
> > > > On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > > > <[hidden email]> wrote:
> > > >>
> > > >> Agree, let's mark MVCC experimental.
> > > >>
> > > >> Stephen, the annotation serves as an additional documentation-style
> > > marker.
> > > >> For now there are no compile-time warnings when the API is used.
> > > >>
> > > >> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > > >> [hidden email]>:
> > > >>
> > > >>> Yes! I’ve already seen people try to use this without awareness that
> > > it’s
> > > >>> not production ready.
> > > >>>
> > > >>> What happens with the annotation, incidentally? Is it just in the
> > > >>> documentation or do you get a compile-time warning?
> > > >>>
> > > >>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]> wrote:
> > > >>>>
> > > >>>> Hello, Igniters.
> > > >>>>
> > > >>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > > >>>>
> > > >>>> We explicitly note users that MVCC has beta status, for now [1]
> > > >>>>
> > > >>>>> Beta version of Transactional SQL and MVCC
> > > >>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> > > >>> versions to allow users to experiment and share feedback.
> > > >>>>> This version of Transactional SQL and MVCC should not be considered
> > > for
> > > >>> production.
> > > >>>>
> > > >>>>
> > > >>>> [1]
> > > https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>>
> > >
> > >

[Alexey Goncharuk]

Not sure where we got the idea that MVCC code is useless in master.

Alexei,

I know that you used the MVCC partition counters implementation in order to
fix tx & atomic caches protocol issues. The MVCC WAL backpointer mechanics
can and should be used when we will move transaction records logging from
COMMITTING stage to PREPARING stage. Current cache entry versioning
mechanics can be used to allow faster reads inside transactions, direct
offheap scans and many other optimizations.

We should work on processes to prevent such merges in the future, but not
waste time reverting something that can be used for profit.

[Nikolay Izhikov-2]

Hell, Alexey.

> We should work on processes to prevent such merges in the future, but not waste time reverting something that can be used for profit.

Can you, please, clarify, what real-world use-cases for the current implementation of MVCC exists?

> 7 февр. 2020 г., в 13:07, Alexey Goncharuk <[hidden email]> написал(а):
>
> Not sure where we got the idea that MVCC code is useless in master.
>
> Alexei,
>
> I know that you used the MVCC partition counters implementation in order to
> fix tx & atomic caches protocol issues. The MVCC WAL backpointer mechanics
> can and should be used when we will move transaction records logging from
> COMMITTING stage to PREPARING stage. Current cache entry versioning
> mechanics can be used to allow faster reads inside transactions, direct
> offheap scans and many other optimizations.
>
> We should work on processes to prevent such merges in the future, but not
> waste time reverting something that can be used for profit.

[gvvinblade]

Note that someone uses it

Main problem is a recovery process when persistence enabled and a cluster have more than one node.

It is a problem even for regular transactional caches, the main difference - MVCC detects any inconsistencies while regular transactional caches may ignore it without any notification

In other cases it works fine and provides promised guaranties.

Of course there are several minor issues like performance ones, but there is a plan how to solve them (I could share it if anybody is curious)

My opinion we should solve consistency issues first and finalize MVCC after that.

Until that it’s OK to have it as experimental feature.

Regards,
Igor

> 6 февр. 2020 г., в 21:25, Alexei Scherbakov <[hidden email]> написал(а):
>
> I'm strongly support removal of MVCC from master.
>
> At the current state it bloats code base and should be reworked from
> scratch using separate code base.
>
> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <[hidden email]>:
>
>> Hello!
>>
>> Please keep in mind that you need to create a separate proposal voting
>> thread if you really like it to count. I wonder if Dmitry Pavlov can help
>> us with the procedure.
>>
>> Otherwise, I think it makes total sense to restrict MVCC clusters to only
>> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in
>> our current implementation) and no ATOMIC caches at all.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
>>
>>> Ilya,
>>>
>>>
>>> 1. MVCC support requires code maintenance for other developed features
>>> even if has not used and disabled. Currently, we've got an x2 level of
>>> difficulty for implementation of new features.
>>>
>>> 2. It would be much easy to develop and support clusters with
>>> mvcc-caches only rather than have a mixed configuration. With this
>>> option we can dramatically reduce the amount of codebase removing from
>>> mvcc-branch local, atomic, tx caches.
>>>
>>>
>>> So, I'm +1 to remove it from the master branch and mark the current
>>> API with @IgniteExperimental.
>>>
>>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]>
>>> wrote:
>>>>
>>>> Hello!
>>>>
>>>> Why would we drop MVCC!?
>>>>
>>>> I can totally imagine a scenario where a large Ignite user surfaces
>> with
>>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
>> maybe
>>>> it will graduate to beta some time in future.
>>>>
>>>> If it does too much strain on the TC, let's discuss that, but I don't
>>>> remember problems with TC load lately, so maybe this is a moot point.
>>>>
>>>> Regards,
>>>> --
>>>> Ilya Kasnacheev
>>>>
>>>>
>>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
>>>>
>>>>>> By the way, is there any reason to have this code in the master
>>> branch
>>>>>
>>>>> I support removal MVCC from master.
>>>>>
>>>>>
>>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
>> написал(а):
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> By the way, is there any reason to have this code in the master
>>>>>> branch? It seems feature is in unsupportable state and just wastes
>> TC
>>>>>> time and our effort to support MVCC related tests.
>>>>>>
>>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Agree, let's mark MVCC experimental.
>>>>>>>
>>>>>>> Stephen, the annotation serves as an additional
>> documentation-style
>>>>> marker.
>>>>>>> For now there are no compile-time warnings when the API is used.
>>>>>>>
>>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
>>>>>>> [hidden email]>:
>>>>>>>
>>>>>>>> Yes! I’ve already seen people try to use this without awareness
>>> that
>>>>> it’s
>>>>>>>> not production ready.
>>>>>>>>
>>>>>>>> What happens with the annotation, incidentally? Is it just in the
>>>>>>>> documentation or do you get a compile-time warning?
>>>>>>>>
>>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello, Igniters.
>>>>>>>>>
>>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
>>>>>>>>>
>>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
>>>>>>>>>
>>>>>>>>>> Beta version of Transactional SQL and MVCC
>>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
>>>>>>>> versions to allow users to experiment and share feedback.
>>>>>>>>>> This version of Transactional SQL and MVCC should not be
>>> considered
>>>>> for
>>>>>>>> production.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1]
>>>>> https://apacheignite.readme.io/docs/multiversion-concurrency-control
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov

[Ivan Pavlukhin]

My humble opinion.

We need MVCC because it is our way to SQL transactions. SQL is a very
important user API (as you might know there is an active work on new
SQL engine). Fair SQL transactions is a supplementary and quite needed
feature, users ask about it on user list. I believe it is a future of
Ignite.

Best regards,
Ivan Pavlukhin

пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <[hidden email]>:

>
> Note that someone uses it
>
> Main problem is a recovery process when persistence enabled and a cluster have more than one node.
>
> It is a problem even for regular transactional caches, the main difference - MVCC detects any inconsistencies while regular transactional caches may ignore it without any notification
>
> In other cases it works fine and provides promised guaranties.
>
> Of course there are several minor issues like performance ones, but there is a plan how to solve them (I could share it if anybody is curious)
>
> My opinion we should solve consistency issues first and finalize MVCC after that.
>
> Until that it’s OK to have it as experimental feature.
>
> Regards,
> Igor
>
> > 6 февр. 2020 г., в 21:25, Alexei Scherbakov <[hidden email]> написал(а):
> >
> > I'm strongly support removal of MVCC from master.
> >
> > At the current state it bloats code base and should be reworked from
> > scratch using separate code base.
> >
> > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <[hidden email]>:
> >
> >> Hello!
> >>
> >> Please keep in mind that you need to create a separate proposal voting
> >> thread if you really like it to count. I wonder if Dmitry Pavlov can help
> >> us with the procedure.
> >>
> >> Otherwise, I think it makes total sense to restrict MVCC clusters to only
> >> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they compatible in
> >> our current implementation) and no ATOMIC caches at all.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
> >>
> >>> Ilya,
> >>>
> >>>
> >>> 1. MVCC support requires code maintenance for other developed features
> >>> even if has not used and disabled. Currently, we've got an x2 level of
> >>> difficulty for implementation of new features.
> >>>
> >>> 2. It would be much easy to develop and support clusters with
> >>> mvcc-caches only rather than have a mixed configuration. With this
> >>> option we can dramatically reduce the amount of codebase removing from
> >>> mvcc-branch local, atomic, tx caches.
> >>>
> >>>
> >>> So, I'm +1 to remove it from the master branch and mark the current
> >>> API with @IgniteExperimental.
> >>>
> >>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <[hidden email]>
> >>> wrote:
> >>>>
> >>>> Hello!
> >>>>
> >>>> Why would we drop MVCC!?
> >>>>
> >>>> I can totally imagine a scenario where a large Ignite user surfaces
> >> with
> >>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
> >> maybe
> >>>> it will graduate to beta some time in future.
> >>>>
> >>>> If it does too much strain on the TC, let's discuss that, but I don't
> >>>> remember problems with TC load lately, so maybe this is a moot point.
> >>>>
> >>>> Regards,
> >>>> --
> >>>> Ilya Kasnacheev
> >>>>
> >>>>
> >>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> >>>>
> >>>>>> By the way, is there any reason to have this code in the master
> >>> branch
> >>>>>
> >>>>> I support removal MVCC from master.
> >>>>>
> >>>>>
> >>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> >> написал(а):
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> By the way, is there any reason to have this code in the master
> >>>>>> branch? It seems feature is in unsupportable state and just wastes
> >> TC
> >>>>>> time and our effort to support MVCC related tests.
> >>>>>>
> >>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> >>>>>> <[hidden email]> wrote:
> >>>>>>>
> >>>>>>> Agree, let's mark MVCC experimental.
> >>>>>>>
> >>>>>>> Stephen, the annotation serves as an additional
> >> documentation-style
> >>>>> marker.
> >>>>>>> For now there are no compile-time warnings when the API is used.
> >>>>>>>
> >>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> >>>>>>> [hidden email]>:
> >>>>>>>
> >>>>>>>> Yes! I’ve already seen people try to use this without awareness
> >>> that
> >>>>> it’s
> >>>>>>>> not production ready.
> >>>>>>>>
> >>>>>>>> What happens with the annotation, incidentally? Is it just in the
> >>>>>>>> documentation or do you get a compile-time warning?
> >>>>>>>>
> >>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> >>> wrote:
> >>>>>>>>>
> >>>>>>>>> Hello, Igniters.
> >>>>>>>>>
> >>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
> >>>>>>>>>
> >>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
> >>>>>>>>>
> >>>>>>>>>> Beta version of Transactional SQL and MVCC
> >>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as beta
> >>>>>>>> versions to allow users to experiment and share feedback.
> >>>>>>>>>> This version of Transactional SQL and MVCC should not be
> >>> considered
> >>>>> for
> >>>>>>>> production.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> [1]
> >>>>> https://apacheignite.readme.io/docs/multiversion-concurrency-control
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
>

[Alexei Scherbakov]

My point is MVCC should be redone from scratch without messing with other
pars of code.

Currently it's spaghetti unmaintanable code.

пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin <[hidden email]>:

> My humble opinion.
>
> We need MVCC because it is our way to SQL transactions. SQL is a very
> important user API (as you might know there is an active work on new
> SQL engine). Fair SQL transactions is a supplementary and quite needed
> feature, users ask about it on user list. I believe it is a future of
> Ignite.
>
> Best regards,
> Ivan Pavlukhin
>
> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <[hidden email]>:
> >
> > Note that someone uses it
> >
> > Main problem is a recovery process when persistence enabled and a
> cluster have more than one node.
> >
> > It is a problem even for regular transactional caches, the main
> difference - MVCC detects any inconsistencies while regular transactional
> caches may ignore it without any notification
> >
> > In other cases it works fine and provides promised guaranties.
> >
> > Of course there are several minor issues like performance ones, but
> there is a plan how to solve them (I could share it if anybody is curious)
> >
> > My opinion we should solve consistency issues first and finalize MVCC
> after that.
> >
> > Until that it’s OK to have it as experimental feature.
> >
> > Regards,
> > Igor
> >
> > > 6 февр. 2020 г., в 21:25, Alexei Scherbakov <
> [hidden email]> написал(а):
> > >
> > > I'm strongly support removal of MVCC from master.
> > >
> > > At the current state it bloats code base and should be reworked from
> > > scratch using separate code base.
> > >
> > > чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <
> [hidden email]>:
> > >
> > >> Hello!
> > >>
> > >> Please keep in mind that you need to create a separate proposal voting
> > >> thread if you really like it to count. I wonder if Dmitry Pavlov can
> help
> > >> us with the procedure.
> > >>
> > >> Otherwise, I think it makes total sense to restrict MVCC clusters to
> only
> > >> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they
> compatible in
> > >> our current implementation) and no ATOMIC caches at all.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
> > >>
> > >>> Ilya,
> > >>>
> > >>>
> > >>> 1. MVCC support requires code maintenance for other developed
> features
> > >>> even if has not used and disabled. Currently, we've got an x2 level
> of
> > >>> difficulty for implementation of new features.
> > >>>
> > >>> 2. It would be much easy to develop and support clusters with
> > >>> mvcc-caches only rather than have a mixed configuration. With this
> > >>> option we can dramatically reduce the amount of codebase removing
> from
> > >>> mvcc-branch local, atomic, tx caches.
> > >>>
> > >>>
> > >>> So, I'm +1 to remove it from the master branch and mark the current
> > >>> API with @IgniteExperimental.
> > >>>
> > >>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <
> [hidden email]>
> > >>> wrote:
> > >>>>
> > >>>> Hello!
> > >>>>
> > >>>> Why would we drop MVCC!?
> > >>>>
> > >>>> I can totally imagine a scenario where a large Ignite user surfaces
> > >> with
> > >>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
> > >> maybe
> > >>>> it will graduate to beta some time in future.
> > >>>>
> > >>>> If it does too much strain on the TC, let's discuss that, but I
> don't
> > >>>> remember problems with TC load lately, so maybe this is a moot
> point.
> > >>>>
> > >>>> Regards,
> > >>>> --
> > >>>> Ilya Kasnacheev
> > >>>>
> > >>>>
> > >>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> > >>>>
> > >>>>>> By the way, is there any reason to have this code in the master
> > >>> branch
> > >>>>>
> > >>>>> I support removal MVCC from master.
> > >>>>>
> > >>>>>
> > >>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> > >> написал(а):
> > >>>>>>
> > >>>>>> +1
> > >>>>>>
> > >>>>>> By the way, is there any reason to have this code in the master
> > >>>>>> branch? It seems feature is in unsupportable state and just wastes
> > >> TC
> > >>>>>> time and our effort to support MVCC related tests.
> > >>>>>>
> > >>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > >>>>>> <[hidden email]> wrote:
> > >>>>>>>
> > >>>>>>> Agree, let's mark MVCC experimental.
> > >>>>>>>
> > >>>>>>> Stephen, the annotation serves as an additional
> > >> documentation-style
> > >>>>> marker.
> > >>>>>>> For now there are no compile-time warnings when the API is used.
> > >>>>>>>
> > >>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > >>>>>>> [hidden email]>:
> > >>>>>>>
> > >>>>>>>> Yes! I’ve already seen people try to use this without awareness
> > >>> that
> > >>>>> it’s
> > >>>>>>>> not production ready.
> > >>>>>>>>
> > >>>>>>>> What happens with the annotation, incidentally? Is it just in
> the
> > >>>>>>>> documentation or do you get a compile-time warning?
> > >>>>>>>>
> > >>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> > >>> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Hello, Igniters.
> > >>>>>>>>>
> > >>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > >>>>>>>>>
> > >>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
> > >>>>>>>>>
> > >>>>>>>>>> Beta version of Transactional SQL and MVCC
> > >>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as
> beta
> > >>>>>>>> versions to allow users to experiment and share feedback.
> > >>>>>>>>>> This version of Transactional SQL and MVCC should not be
> > >>> considered
> > >>>>> for
> > >>>>>>>> production.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> [1]
> > >>>>>
> https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> >
>

--

Best regards,
Alexei Scherbakov

[Roman Kondakov]

I absolutely agree with Alexey that MVCC architecture should be
completely reviewed. Current implementation is uncompetitive with other
solutions. It is slow by design. Here are some my points:
- we use central coordinator for transactions ordering. This is very
similar to what Calvin [1] systems do. But unlike them we also use 2pc
for distributed commit. So, we always have several additional network
hops for each transaction and every Calvin system (FaunaDB, YandexDB)
will outperform Ignite by design.
- We write uncommitted data to the page memory and WAL and this slows
down transactions even more.

I am a supporter of complete revising of the MVCC design.

[1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf

--
Kind Regards
Roman Kondakov


On 07.02.2020 15:21, Alexei Scherbakov wrote:

> My point is MVCC should be redone from scratch without messing with other
> pars of code.
>
> Currently it's spaghetti unmaintanable code.
>
> пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin <[hidden email]>:
>
>> My humble opinion.
>>
>> We need MVCC because it is our way to SQL transactions. SQL is a very
>> important user API (as you might know there is an active work on new
>> SQL engine). Fair SQL transactions is a supplementary and quite needed
>> feature, users ask about it on user list. I believe it is a future of
>> Ignite.
>>
>> Best regards,
>> Ivan Pavlukhin
>>
>> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <[hidden email]>:
>>>
>>> Note that someone uses it
>>>
>>> Main problem is a recovery process when persistence enabled and a
>> cluster have more than one node.
>>>
>>> It is a problem even for regular transactional caches, the main
>> difference - MVCC detects any inconsistencies while regular transactional
>> caches may ignore it without any notification
>>>
>>> In other cases it works fine and provides promised guaranties.
>>>
>>> Of course there are several minor issues like performance ones, but
>> there is a plan how to solve them (I could share it if anybody is curious)
>>>
>>> My opinion we should solve consistency issues first and finalize MVCC
>> after that.
>>>
>>> Until that it’s OK to have it as experimental feature.
>>>
>>> Regards,
>>> Igor
>>>
>>>> 6 февр. 2020 г., в 21:25, Alexei Scherbakov <
>> [hidden email]> написал(а):
>>>>
>>>> I'm strongly support removal of MVCC from master.
>>>>
>>>> At the current state it bloats code base and should be reworked from
>>>> scratch using separate code base.
>>>>
>>>> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <
>> [hidden email]>:
>>>>
>>>>> Hello!
>>>>>
>>>>> Please keep in mind that you need to create a separate proposal voting
>>>>> thread if you really like it to count. I wonder if Dmitry Pavlov can
>> help
>>>>> us with the procedure.
>>>>>
>>>>> Otherwise, I think it makes total sense to restrict MVCC clusters to
>> only
>>>>> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they
>> compatible in
>>>>> our current implementation) and no ATOMIC caches at all.
>>>>>
>>>>> Regards,
>>>>> --
>>>>> Ilya Kasnacheev
>>>>>
>>>>>
>>>>> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
>>>>>
>>>>>> Ilya,
>>>>>>
>>>>>>
>>>>>> 1. MVCC support requires code maintenance for other developed
>> features
>>>>>> even if has not used and disabled. Currently, we've got an x2 level
>> of
>>>>>> difficulty for implementation of new features.
>>>>>>
>>>>>> 2. It would be much easy to develop and support clusters with
>>>>>> mvcc-caches only rather than have a mixed configuration. With this
>>>>>> option we can dramatically reduce the amount of codebase removing
>> from
>>>>>> mvcc-branch local, atomic, tx caches.
>>>>>>
>>>>>>
>>>>>> So, I'm +1 to remove it from the master branch and mark the current
>>>>>> API with @IgniteExperimental.
>>>>>>
>>>>>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <
>> [hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello!
>>>>>>>
>>>>>>> Why would we drop MVCC!?
>>>>>>>
>>>>>>> I can totally imagine a scenario where a large Ignite user surfaces
>>>>> with
>>>>>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
>>>>> maybe
>>>>>>> it will graduate to beta some time in future.
>>>>>>>
>>>>>>> If it does too much strain on the TC, let's discuss that, but I
>> don't
>>>>>>> remember problems with TC load lately, so maybe this is a moot
>> point.
>>>>>>>
>>>>>>> Regards,
>>>>>>> --
>>>>>>> Ilya Kasnacheev
>>>>>>>
>>>>>>>
>>>>>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
>>>>>>>
>>>>>>>>> By the way, is there any reason to have this code in the master
>>>>>> branch
>>>>>>>>
>>>>>>>> I support removal MVCC from master.
>>>>>>>>
>>>>>>>>
>>>>>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
>>>>> написал(а):
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> By the way, is there any reason to have this code in the master
>>>>>>>>> branch? It seems feature is in unsupportable state and just wastes
>>>>> TC
>>>>>>>>> time and our effort to support MVCC related tests.
>>>>>>>>>
>>>>>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
>>>>>>>>> <[hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> Agree, let's mark MVCC experimental.
>>>>>>>>>>
>>>>>>>>>> Stephen, the annotation serves as an additional
>>>>> documentation-style
>>>>>>>> marker.
>>>>>>>>>> For now there are no compile-time warnings when the API is used.
>>>>>>>>>>
>>>>>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
>>>>>>>>>> [hidden email]>:
>>>>>>>>>>
>>>>>>>>>>> Yes! I’ve already seen people try to use this without awareness
>>>>>> that
>>>>>>>> it’s
>>>>>>>>>>> not production ready.
>>>>>>>>>>>
>>>>>>>>>>> What happens with the annotation, incidentally? Is it just in
>> the
>>>>>>>>>>> documentation or do you get a compile-time warning?
>>>>>>>>>>>
>>>>>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hello, Igniters.
>>>>>>>>>>>>
>>>>>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
>>>>>>>>>>>>
>>>>>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
>>>>>>>>>>>>
>>>>>>>>>>>>> Beta version of Transactional SQL and MVCC
>>>>>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as
>> beta
>>>>>>>>>>> versions to allow users to experiment and share feedback.
>>>>>>>>>>>>> This version of Transactional SQL and MVCC should not be
>>>>>> considered
>>>>>>>> for
>>>>>>>>>>> production.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> [1]
>>>>>>>>
>> https://apacheignite.readme.io/docs/multiversion-concurrency-control
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Best regards,
>>>> Alexei Scherbakov
>>>
>>
>
>

[Ivan Pavlukhin]

Folks,

Do we have a consensus so far that MVCC should be annotated with
@IgniteExperimental? Are there any objections?

Best regards,
Ivan Pavlukhin

пт, 7 февр. 2020 г. в 15:58, Roman Kondakov <[hidden email]>:

>
> I absolutely agree with Alexey that MVCC architecture should be
> completely reviewed. Current implementation is uncompetitive with other
> solutions. It is slow by design. Here are some my points:
> - we use central coordinator for transactions ordering. This is very
> similar to what Calvin [1] systems do. But unlike them we also use 2pc
> for distributed commit. So, we always have several additional network
> hops for each transaction and every Calvin system (FaunaDB, YandexDB)
> will outperform Ignite by design.
> - We write uncommitted data to the page memory and WAL and this slows
> down transactions even more.
>
> I am a supporter of complete revising of the MVCC design.
>
> [1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf
>
> --
> Kind Regards
> Roman Kondakov
>
>
> On 07.02.2020 15:21, Alexei Scherbakov wrote:
> > My point is MVCC should be redone from scratch without messing with other
> > pars of code.
> >
> > Currently it's spaghetti unmaintanable code.
> >
> > пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin <[hidden email]>:
> >
> >> My humble opinion.
> >>
> >> We need MVCC because it is our way to SQL transactions. SQL is a very
> >> important user API (as you might know there is an active work on new
> >> SQL engine). Fair SQL transactions is a supplementary and quite needed
> >> feature, users ask about it on user list. I believe it is a future of
> >> Ignite.
> >>
> >> Best regards,
> >> Ivan Pavlukhin
> >>
> >> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <[hidden email]>:
> >>>
> >>> Note that someone uses it
> >>>
> >>> Main problem is a recovery process when persistence enabled and a
> >> cluster have more than one node.
> >>>
> >>> It is a problem even for regular transactional caches, the main
> >> difference - MVCC detects any inconsistencies while regular transactional
> >> caches may ignore it without any notification
> >>>
> >>> In other cases it works fine and provides promised guaranties.
> >>>
> >>> Of course there are several minor issues like performance ones, but
> >> there is a plan how to solve them (I could share it if anybody is curious)
> >>>
> >>> My opinion we should solve consistency issues first and finalize MVCC
> >> after that.
> >>>
> >>> Until that it’s OK to have it as experimental feature.
> >>>
> >>> Regards,
> >>> Igor
> >>>
> >>>> 6 февр. 2020 г., в 21:25, Alexei Scherbakov <
> >> [hidden email]> написал(а):
> >>>>
> >>>> I'm strongly support removal of MVCC from master.
> >>>>
> >>>> At the current state it bloats code base and should be reworked from
> >>>> scratch using separate code base.
> >>>>
> >>>> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <
> >> [hidden email]>:
> >>>>
> >>>>> Hello!
> >>>>>
> >>>>> Please keep in mind that you need to create a separate proposal voting
> >>>>> thread if you really like it to count. I wonder if Dmitry Pavlov can
> >> help
> >>>>> us with the procedure.
> >>>>>
> >>>>> Otherwise, I think it makes total sense to restrict MVCC clusters to
> >> only
> >>>>> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they
> >> compatible in
> >>>>> our current implementation) and no ATOMIC caches at all.
> >>>>>
> >>>>> Regards,
> >>>>> --
> >>>>> Ilya Kasnacheev
> >>>>>
> >>>>>
> >>>>> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
> >>>>>
> >>>>>> Ilya,
> >>>>>>
> >>>>>>
> >>>>>> 1. MVCC support requires code maintenance for other developed
> >> features
> >>>>>> even if has not used and disabled. Currently, we've got an x2 level
> >> of
> >>>>>> difficulty for implementation of new features.
> >>>>>>
> >>>>>> 2. It would be much easy to develop and support clusters with
> >>>>>> mvcc-caches only rather than have a mixed configuration. With this
> >>>>>> option we can dramatically reduce the amount of codebase removing
> >> from
> >>>>>> mvcc-branch local, atomic, tx caches.
> >>>>>>
> >>>>>>
> >>>>>> So, I'm +1 to remove it from the master branch and mark the current
> >>>>>> API with @IgniteExperimental.
> >>>>>>
> >>>>>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <
> >> [hidden email]>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello!
> >>>>>>>
> >>>>>>> Why would we drop MVCC!?
> >>>>>>>
> >>>>>>> I can totally imagine a scenario where a large Ignite user surfaces
> >>>>> with
> >>>>>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
> >>>>> maybe
> >>>>>>> it will graduate to beta some time in future.
> >>>>>>>
> >>>>>>> If it does too much strain on the TC, let's discuss that, but I
> >> don't
> >>>>>>> remember problems with TC load lately, so maybe this is a moot
> >> point.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> --
> >>>>>>> Ilya Kasnacheev
> >>>>>>>
> >>>>>>>
> >>>>>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> >>>>>>>
> >>>>>>>>> By the way, is there any reason to have this code in the master
> >>>>>> branch
> >>>>>>>>
> >>>>>>>> I support removal MVCC from master.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> >>>>> написал(а):
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> By the way, is there any reason to have this code in the master
> >>>>>>>>> branch? It seems feature is in unsupportable state and just wastes
> >>>>> TC
> >>>>>>>>> time and our effort to support MVCC related tests.
> >>>>>>>>>
> >>>>>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> >>>>>>>>> <[hidden email]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Agree, let's mark MVCC experimental.
> >>>>>>>>>>
> >>>>>>>>>> Stephen, the annotation serves as an additional
> >>>>> documentation-style
> >>>>>>>> marker.
> >>>>>>>>>> For now there are no compile-time warnings when the API is used.
> >>>>>>>>>>
> >>>>>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> >>>>>>>>>> [hidden email]>:
> >>>>>>>>>>
> >>>>>>>>>>> Yes! I’ve already seen people try to use this without awareness
> >>>>>> that
> >>>>>>>> it’s
> >>>>>>>>>>> not production ready.
> >>>>>>>>>>>
> >>>>>>>>>>> What happens with the annotation, incidentally? Is it just in
> >> the
> >>>>>>>>>>> documentation or do you get a compile-time warning?
> >>>>>>>>>>>
> >>>>>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> >>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hello, Igniters.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
> >>>>>>>>>>>>
> >>>>>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Beta version of Transactional SQL and MVCC
> >>>>>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as
> >> beta
> >>>>>>>>>>> versions to allow users to experiment and share feedback.
> >>>>>>>>>>>>> This version of Transactional SQL and MVCC should not be
> >>>>>> considered
> >>>>>>>> for
> >>>>>>>>>>> production.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1]
> >>>>>>>>
> >> https://apacheignite.readme.io/docs/multiversion-concurrency-control
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Best regards,
> >>>> Alexei Scherbakov
> >>>
> >>
> >
> >

[Maxim Muzafarov]

Ivan,


Seem the answer is "yes, we've got consensus".
The issue [1] created.


[1] https://issues.apache.org/jira/browse/IGNITE-12650

On Fri, 7 Feb 2020 at 21:33, Ivan Pavlukhin <[hidden email]> wrote:

>
> Folks,
>
> Do we have a consensus so far that MVCC should be annotated with
> @IgniteExperimental? Are there any objections?
>
> Best regards,
> Ivan Pavlukhin
>
> пт, 7 февр. 2020 г. в 15:58, Roman Kondakov <[hidden email]>:
> >
> > I absolutely agree with Alexey that MVCC architecture should be
> > completely reviewed. Current implementation is uncompetitive with other
> > solutions. It is slow by design. Here are some my points:
> > - we use central coordinator for transactions ordering. This is very
> > similar to what Calvin [1] systems do. But unlike them we also use 2pc
> > for distributed commit. So, we always have several additional network
> > hops for each transaction and every Calvin system (FaunaDB, YandexDB)
> > will outperform Ignite by design.
> > - We write uncommitted data to the page memory and WAL and this slows
> > down transactions even more.
> >
> > I am a supporter of complete revising of the MVCC design.
> >
> > [1] http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf
> >
> > --
> > Kind Regards
> > Roman Kondakov
> >
> >
> > On 07.02.2020 15:21, Alexei Scherbakov wrote:
> > > My point is MVCC should be redone from scratch without messing with other
> > > pars of code.
> > >
> > > Currently it's spaghetti unmaintanable code.
> > >
> > > пт, 7 февр. 2020 г. в 14:52, Ivan Pavlukhin <[hidden email]>:
> > >
> > >> My humble opinion.
> > >>
> > >> We need MVCC because it is our way to SQL transactions. SQL is a very
> > >> important user API (as you might know there is an active work on new
> > >> SQL engine). Fair SQL transactions is a supplementary and quite needed
> > >> feature, users ask about it on user list. I believe it is a future of
> > >> Ignite.
> > >>
> > >> Best regards,
> > >> Ivan Pavlukhin
> > >>
> > >> пт, 7 февр. 2020 г. в 13:23, Seliverstov Igor <[hidden email]>:
> > >>>
> > >>> Note that someone uses it
> > >>>
> > >>> Main problem is a recovery process when persistence enabled and a
> > >> cluster have more than one node.
> > >>>
> > >>> It is a problem even for regular transactional caches, the main
> > >> difference - MVCC detects any inconsistencies while regular transactional
> > >> caches may ignore it without any notification
> > >>>
> > >>> In other cases it works fine and provides promised guaranties.
> > >>>
> > >>> Of course there are several minor issues like performance ones, but
> > >> there is a plan how to solve them (I could share it if anybody is curious)
> > >>>
> > >>> My opinion we should solve consistency issues first and finalize MVCC
> > >> after that.
> > >>>
> > >>> Until that it’s OK to have it as experimental feature.
> > >>>
> > >>> Regards,
> > >>> Igor
> > >>>
> > >>>> 6 февр. 2020 г., в 21:25, Alexei Scherbakov <
> > >> [hidden email]> написал(а):
> > >>>>
> > >>>> I'm strongly support removal of MVCC from master.
> > >>>>
> > >>>> At the current state it bloats code base and should be reworked from
> > >>>> scratch using separate code base.
> > >>>>
> > >>>> чт, 6 февр. 2020 г. в 19:45, Ilya Kasnacheev <
> > >> [hidden email]>:
> > >>>>
> > >>>>> Hello!
> > >>>>>
> > >>>>> Please keep in mind that you need to create a separate proposal voting
> > >>>>> thread if you really like it to count. I wonder if Dmitry Pavlov can
> > >> help
> > >>>>> us with the procedure.
> > >>>>>
> > >>>>> Otherwise, I think it makes total sense to restrict MVCC clusters to
> > >> only
> > >>>>> have MVCC caches or REPLICATED TRANSACTIONAL caches (are they
> > >> compatible in
> > >>>>> our current implementation) and no ATOMIC caches at all.
> > >>>>>
> > >>>>> Regards,
> > >>>>> --
> > >>>>> Ilya Kasnacheev
> > >>>>>
> > >>>>>
> > >>>>> чт, 6 февр. 2020 г. в 19:41, Maxim Muzafarov <[hidden email]>:
> > >>>>>
> > >>>>>> Ilya,
> > >>>>>>
> > >>>>>>
> > >>>>>> 1. MVCC support requires code maintenance for other developed
> > >> features
> > >>>>>> even if has not used and disabled. Currently, we've got an x2 level
> > >> of
> > >>>>>> difficulty for implementation of new features.
> > >>>>>>
> > >>>>>> 2. It would be much easy to develop and support clusters with
> > >>>>>> mvcc-caches only rather than have a mixed configuration. With this
> > >>>>>> option we can dramatically reduce the amount of codebase removing
> > >> from
> > >>>>>> mvcc-branch local, atomic, tx caches.
> > >>>>>>
> > >>>>>>
> > >>>>>> So, I'm +1 to remove it from the master branch and mark the current
> > >>>>>> API with @IgniteExperimental.
> > >>>>>>
> > >>>>>> On Thu, 6 Feb 2020 at 19:29, Ilya Kasnacheev <
> > >> [hidden email]>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Hello!
> > >>>>>>>
> > >>>>>>> Why would we drop MVCC!?
> > >>>>>>>
> > >>>>>>> I can totally imagine a scenario where a large Ignite user surfaces
> > >>>>> with
> > >>>>>>> fixes for MVCC mode, if it is kept as an experimental feature. Then
> > >>>>> maybe
> > >>>>>>> it will graduate to beta some time in future.
> > >>>>>>>
> > >>>>>>> If it does too much strain on the TC, let's discuss that, but I
> > >> don't
> > >>>>>>> remember problems with TC load lately, so maybe this is a moot
> > >> point.
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> --
> > >>>>>>> Ilya Kasnacheev
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov <[hidden email]>:
> > >>>>>>>
> > >>>>>>>>> By the way, is there any reason to have this code in the master
> > >>>>>> branch
> > >>>>>>>>
> > >>>>>>>> I support removal MVCC from master.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> 6 февр. 2020 г., в 15:26, Andrey Gura <[hidden email]>
> > >>>>> написал(а):
> > >>>>>>>>>
> > >>>>>>>>> +1
> > >>>>>>>>>
> > >>>>>>>>> By the way, is there any reason to have this code in the master
> > >>>>>>>>> branch? It seems feature is in unsupportable state and just wastes
> > >>>>> TC
> > >>>>>>>>> time and our effort to support MVCC related tests.
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
> > >>>>>>>>> <[hidden email]> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Agree, let's mark MVCC experimental.
> > >>>>>>>>>>
> > >>>>>>>>>> Stephen, the annotation serves as an additional
> > >>>>> documentation-style
> > >>>>>>>> marker.
> > >>>>>>>>>> For now there are no compile-time warnings when the API is used.
> > >>>>>>>>>>
> > >>>>>>>>>> чт, 6 февр. 2020 г. в 14:35, Stephen Darlington <
> > >>>>>>>>>> [hidden email]>:
> > >>>>>>>>>>
> > >>>>>>>>>>> Yes! I’ve already seen people try to use this without awareness
> > >>>>>> that
> > >>>>>>>> it’s
> > >>>>>>>>>>> not production ready.
> > >>>>>>>>>>>
> > >>>>>>>>>>> What happens with the annotation, incidentally? Is it just in
> > >> the
> > >>>>>>>>>>> documentation or do you get a compile-time warning?
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On 6 Feb 2020, at 11:32, Nikolay Izhikov <[hidden email]>
> > >>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hello, Igniters.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Should we mark MVCC feature with the new @IgniteExperimental?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> We explicitly note users that MVCC has beta status, for now [1]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Beta version of Transactional SQL and MVCC
> > >>>>>>>>>>>>> In Ignite v2.7, Transactional SQL and MVCC are released as
> > >> beta
> > >>>>>>>>>>> versions to allow users to experiment and share feedback.
> > >>>>>>>>>>>>> This version of Transactional SQL and MVCC should not be
> > >>>>>> considered
> > >>>>>>>> for
> > >>>>>>>>>>> production.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> [1]
> > >>>>>>>>
> > >> https://apacheignite.readme.io/docs/multiversion-concurrency-control
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>> Best regards,
> > >>>> Alexei Scherbakov
> > >>>
> > >>
> > >
> > >