Eventually Consistent API

[Mircea Markus]

Hi,

Re: the eventual consistent API, are there any data grids that expose such an API?

I could only find stores such as Cassandra and and MongoDB having eventual consistency, but these are a bit out of the scope of the spec, IMO.

Cheers,

Mircea

[Alex Snaps]

So reading the details on the wiki, it "merely" is about an API to resolve conflicts. 

The proposed API talks about Version (which I haven't seen defined. How are things getting versioned?), of ways to potentially retrieved versioned data and how to resolve conflicts (which we don't know how these conflicts occur?). 

But before thinking in those terms, I guess we need to define "eventual consistency" altogether. 

What I read between the lines from the above, is that anything that makes it in the grid, e.g. put(K, V), gets versioned somehow and that when the <K, V, Version> triplet arrives where the authority is, it'll make sure it only is applied if no newer version is already there, is that right ? How does that define "eventual consistency" for us ? 

I expect the vendors amongst us here to have some strong opinions on this (based on what they currently support), but I will hold off pushing for the best option, which is ours obviously ;)

--
You received this message because you are subscribed to the Google Groups "JSR 347 discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr347+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex Snaps <alex....@gmail.com>
Principal Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
http://withinthefra.me

[Mircea Markus]

Would be good to see Manik's thoughts on this as well, but here is my understanding:

On Wednesday, April 9, 2014 5:42:19 PM UTC+1, Alex Snaps wrote:

So reading the details on the wiki, it "merely" is about an API to resolve conflicts. 

The proposed API talks about Version (which I haven't seen defined. How are things getting versioned?), of ways to potentially retrieved versioned data and how to resolve conflicts (which we don't know how these conflicts occur?). 

The API and the versioning is inspired from the Amazon Dynamo paper (section 4.4): http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

Conflicts occur when the same data/key is updated in two partitions which are then merged. 

But before thinking in those terms, I guess we need to define "eventual consistency" altogether. 

What I read between the lines from the above, is that anything that makes it in the grid, e.g. put(K, V), gets versioned somehow and that when the <K, V, Version> triplet arrives where the authority is, it'll make sure it only is applied if no newer version is already there, is that right ? How does that define "eventual consistency" for us ? 

I think the dynamo paper from which this requirement has been inspired defines it pretty well:

"Dynamo provides eventual consistency, which allows for updates 

to be propagated to all replicas asynchronously. A put() call may 

return to its caller before the update has been applied at all the 

replicas, which can result in scenarios where a subsequent get() 

operation may return an object that does not have the latest 

updates"

 

I expect the vendors amongst us here to have some strong opinions on this (based on what they currently support), but I will hold off pushing for the best option, which is ours obviously ;)

Eventual consistency is a way to achieve Partition tolerance by sacrificing Consistency: users might see stale (inconsistent) data in the presence of network failures.

Here's Infinispan take on handling split-branins: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions

On the short: ATM we don't have, nor plan to add in the near feature an versioned-based API as the one in the JSR347 wiki[1]  for handling cluster partitions. Our current approach is to sacrifice Availability (allow the user the decide actually if he/she still want the cluster to run in the presence of partitions). I'm curious though if there are vendors that have such an API. If there are no vendors with such an API, not sure it's worth considering it for JSR347 either.

 

[1] https://github.com/datagrids/spec/wiki/Proposed-features

On Wed, Apr 9, 2014 at 11:16 AM, Mircea Markus <mircea...@gmail.com> wrote:

Hi,

Re: the eventual consistent API, are there any data grids that expose such an API?

I could only find stores such as Cassandra and and MongoDB having eventual consistency, but these are a bit out of the scope of the spec, IMO.

Cheers,

Mircea

--
You received this message because you are subscribed to the Google Groups "JSR 347 discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jsr347+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alex Snaps]

Warning: Am kinda playing the devil's advocate below...

On Thu, Apr 10, 2014 at 1:20 PM, Mircea Markus <mircea...@gmail.com> wrote:

Would be good to see Manik's thoughts on this as well, but here is my understanding:

On Wednesday, April 9, 2014 5:42:19 PM UTC+1, Alex Snaps wrote:

So reading the details on the wiki, it "merely" is about an API to resolve conflicts. 

The proposed API talks about Version (which I haven't seen defined. How are things getting versioned?), of ways to potentially retrieved versioned data and how to resolve conflicts (which we don't know how these conflicts occur?). 

The API and the versioning is inspired from the Amazon Dynamo paper (section 4.4): http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

Conflicts occur when the same data/key is updated in two partitions which are then merged. 

Right, so this means even in the absence of a partition. Meaning that a merge can happen at any time and therefore the API is required. That makes sense, is it what we want though (i.e. that the system asynchronously applies changes at all times... by spec) or should that only be one "mode" of operation ?

 

But before thinking in those terms, I guess we need to define "eventual consistency" altogether. 

What I read between the lines from the above, is that anything that makes it in the grid, e.g. put(K, V), gets versioned somehow and that when the <K, V, Version> triplet arrives where the authority is, it'll make sure it only is applied if no newer version is already there, is that right ? How does that define "eventual consistency" for us ? 

I think the dynamo paper from which this requirement has been inspired defines it pretty well:

"Dynamo provides eventual consistency, which allows for updates 

to be propagated to all replicas asynchronously. A put() call may 

return to its caller before the update has been applied at all the 

replicas, which can result in scenarios where a subsequent get() 

operation may return an object that does not have the latest 

updates"

No monotonic reads? Again, is it what we want (i.e. only given no activity the state will converge)? No guarantees what so ever... Especially with the above, it may seem a little light in terms of spec, wouldn't it?

 

 

I expect the vendors amongst us here to have some strong opinions on this (based on what they currently support), but I will hold off pushing for the best option, which is ours obviously ;)

Eventual consistency is a way to achieve Partition tolerance by sacrificing Consistency: users might see stale (inconsistent) data in the presence of network failures.

Here's Infinispan take on handling split-branins: https://github.com/infinispan/infinispan/wiki/Handling-cluster-partitions

On the short: ATM we don't have, nor plan to add in the near feature an versioned-based API as the one in the JSR347 wiki[1]  for handling cluster partitions. Our current approach is to sacrifice Availability (allow the user the decide actually if he/she still want the cluster to run in the presence of partitions). I'm curious though if there are vendors that have such an API. If there are no vendors with such an API, not sure it's worth considering it for JSR347 either.

We currently provide these options in the face of a partition: throw always, noop, local-reads with either exception or noop on write. Where being partition is defined not only in terms of connectivity, but also in terms of liveliness, i.e. you can say this op needs to happen within that timespan, otherwise fallback to partitioned behavior. 

This is what I was hinting to when I said we should define what the spec means with being partitioned (amongst other terms): not being able to communicate with a node (within a given time frame); split-brained; the node being identified as down (gone from the topology, but does that happen after a while only? So that during that "while", all operations are blocking until the node is marked as down?); ... a typical example is a node going in full GC for "too long" (according to the SLA put in the grid), it's not gone, it's just ... very slow for a little while.

Probably agreeing on such definition will then help us nail down what features (and APIs) are required to deal properly with these cases. Hope this makes some sense.

 

 

[1] https://github.com/datagrids/spec/wiki/Proposed-features

On Wed, Apr 9, 2014 at 11:16 AM, Mircea Markus <mircea...@gmail.com> wrote:

Hi,

Re: the eventual consistent API, are there any data grids that expose such an API?

I could only find stores such as Cassandra and and MongoDB having eventual consistency, but these are a bit out of the scope of the spec, IMO.

Cheers,

Mircea

--
You received this message because you are subscribed to the Google Groups "JSR 347 discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jsr347+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex Snaps <alex....@gmail.com>
Principal Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
http://withinthefra.me

--
You received this message because you are subscribed to the Google Groups "JSR 347 discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jsr347+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.