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 wrote:
>
> Folks,
>
> Do we have a consensus so far that MVCC should be annotated with
> @IgniteExperimental? Are ther
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 :
>
> I absolutely agree with Alexey that MVCC architecture should be
> completely reviewed. Current imp
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 d
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 :
> My humble opinion.
>
> We need MVCC because it is our way to SQL transactions. SQL is a very
> important user API (
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
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 a
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 Gonchar
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 f
> 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
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'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 :
> Hello!
>
> Please keep in mind that you need to create a separate proposal voting
> thread if
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 cac
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 mix
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
r
> 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 написал(а):
>
> +1
>
> By the way, is there any reason to have this code in the master
> branch? It seems feature is in unsupportable state and
+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
wrote:
>
> Agree, let's mark MVCC experimental.
>
> Stephen,
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 <
stephen.darling...@gridgain.com>:
> Yes! I’ve already seen people tr
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 <
stephen.darling...@gridgain.com>:
> Yes! I’ve already seen people try to use this without awareness that it’s
> not production re
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 wrote:
>
> Hello, Igniters.
>
> Sho
19 matches
Mail list logo
