Hello,
Le 20/02/2020 à 03:22, Tellier Benoit a écrit :
Hello Raphael.
You mention risk of cancelling a legitimate action that could have been
taken as an inconsistency.
To prevent that, a strategy based on delays could be effective as well:
- Detect all the inconsistencies
- Wait long enough to be sure ongoing operations are finished. 2 times
the Cassandra driver time out should be enough.
I don't see how you expect waiting for some time on one node of a
distributed system can help. Distributed concensus cannot be resolved
just by waiting some time on one node.
- Confirm the inconsistency
- Then fix it.
You still have the exact same window of error: between "confirm the
inconsistency" and "fix it" a concurrent operation can happen, either on
the same server, or on an other one.
Telling that the solution is pretty simple, if you can "fix it" in a
lightweight transaction assuring your assumption is correct.
(night is generally of good advice)
On 19/02/2020 23:27, Raphaël Ouazana-Sustowski wrote:
Hello,
My main concern is that trying to solve some inconsistencies, we risk to
introduce some incorrectness.
Your proposal is probably reducing the window of error, but it
potentially adds errors where we had only inconsistencies. Do we accept
that trade-off?
An inconsistency is an error in itself, so I am.
IMHO not the same kind of error. An inconsistency is an error that has
been reported to the user. Here we can potentially blindly change some
valid data without warning the user.
Regards,
Raphaël.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
