Eventual consistency vs. eventual Consistency
K.S. Bhaskar
instances eventually have the same end state. In some cases, this is
insufficient, and they must end up with the same path through state
space. I refer to this as eventual Consistency (from the ACID
properties) and have written about it at
http://ksbhaskar.blogspot.com/2011/03/eventual-consistency-vs-eventual.html
Regards
-- Bhaskar
--
GT.M - Rock solid. Lightning fast. Secure. No compromises.
John D. Mitchell
On Mar 13, 2011, at 12:04 , K.S. Bhaskar wrote:
> For many databases, eventual consistency means that discrete database
> instances eventually have the same end state. In some cases, this is
> insufficient, and they must end up with the same path through state
> space. I refer to this as eventual Consistency (from the ACID
> properties) and have written about it at
> http://ksbhaskar.blogspot.com/2011/03/eventual-consistency-vs-eventual.html
Given your explanation, isn't it more clear (and consistent :-) to
call what you're talking about: "Path Consistency"?
As to the others, it's still unclear to me the motivating examples.
Are the semantics such that you can't use 2PC/quorums or compensations
for some reason?
Thanks,
John
K.S. Bhaskar
On Mar 13, 3:35 pm, "John D. Mitchell" <jdmitch...@gmail.com> wrote:
> Howdy,
>
> On Mar 13, 2011, at 12:04 , K.S. Bhaskar wrote:
>
> > For many databases, eventual consistency means that discrete database
> > instances eventually have the same end state. In some cases, this is
> > insufficient, and they must end up with the same path through state
> > space. I refer to this as eventual Consistency (from the ACID
> > properties) and have written about it at
> Given your explanation, isn't it more clear (and consistent :-) to
> call what you're talking about: "Path Consistency"?
go back and rework the post by and by.
> As to the others, it's still unclear to me the motivating examples.
> Are the semantics such that you can't use 2PC/quorums or compensations
> for some reason?
the instances goes down.
Apropos quorums, consider the case of five instances that get
partitioned into three instances and two instances. The three
instances can perhaps process and commit transactions. Would the two
instances not be able to process and commit transactions? To any
clients connected to the two instances, the application is not
available. In other words, quorums give hybrid ways to handle the
limits of the CAP conjecture. But if the two instances are allowed to
process and commit transactions, then you still have the issue of
detecting collisions and restoring consistency.
Regards
-- Bhaskar
> Thanks,
> John
K.S. Bhaskar
On Mar 13, 5:12 pm, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
> On Mar 13, 3:35 pm, "John D. Mitchell" <jdmitch...@gmail.com> wrote:
>
> > Howdy,
>
> > On Mar 13, 2011, at 12:04 , K.S. Bhaskar wrote:
>
> > > For many databases, eventual consistency means that discrete database
> > > instances eventually have the same end state. In some cases, this is
> > > insufficient, and they must end up with the same path through state
> > > space. I refer to this as eventual Consistency (from the ACID
> > > properties) and have written about it at
> > >http://ksbhaskar.blogspot.com/2011/03/eventual-consistency-vs-eventua...
>
> > Given your explanation, isn't it more clear (and consistent :-) to
> > call what you're talking about: "Path Consistency"?
>
> [KSB] Thank you for the suggestion. That is a much better name. I'll
> go back and rework the post by and by.
Regards
-- Bhaskar
John D. Mitchell
On Mar 13, 2011, at 14:12 , K.S. Bhaskar wrote:
[...]
>> As to the others, it's still unclear to me the motivating examples.
>> Are the semantics such that you can't use 2PC/quorums or
>> compensations
>> for some reason?
>
> [KSB] Two phase commit is not robust in the event the network between
> the instances goes down.
Depends on what your semantics are for the various failure modes.
W.r.t. to "path consistency", I'm missing the "why". If your semantics
require such path consistency then why is e.g. 2PC not perfectly
acceptable (or quorums or...).
> Apropos quorums, consider the case of five instances that get
> partitioned into three instances and two instances. The three
> instances can perhaps process and commit transactions. Would the two
> instances not be able to process and commit transactions? To any
> clients connected to the two instances, the application is not
> available. In other words, quorums give hybrid ways to handle the
> limits of the CAP conjecture. But if the two instances are allowed to
> process and commit transactions, then you still have the issue of
> detecting collisions and restoring consistency.
Well, by definition, since the pair doesn't have a quorum so it must
avoid split brain problems by refusing/degrading service.
It's also unclear to me what the time window presumptions are in your
model but I guess that's just another way of asking you what the
motivating examples are.
Cheers,
John
K.S. Bhaskar
to abstract the concept from implementations, but (after cleaning up
the original post, thanks to suggestions from those on this list and
others), I have now written about Maintaining Eventual Path
Consistency (i.e., detecting Inconsistency and restoring it):
http://ksbhaskar.blogspot.com/2011/04/maintaining-eventual-path-consistency.html
As always, comments are welcome, on list, as comments on the post and
offline.
Regards
-- Bhaskar
On Mar 13, 3:04 pm, "K.S. Bhaskar" <ksbhas...@gmail.com> wrote:
> For many databases, eventual consistency means that discrete database
> instances eventually have the same end state. In some cases, this is
> insufficient, and they must end up with the same path through state
> space. I refer to this as eventual Consistency (from the ACID
>
> Regards
> --Bhaskar