RE: [jr3 trade consistency for availability]

[Marcel Reutegger <mr...@adobe.com>]

> On 29.2.12 15:45, Marcel Reutegger wrote:
> >> Vector clocks. See the presentation [1] which I prepared for the last F2F.
> >
> > I understand this would require tagging each node with a timestamp, right?
> > If that's the case, then it's not just about complexity, but also additional
> > storage requirements.
> 
> Right. But since we version nodes already, we might come up with a
> clever way to reuse the id here. Just an idea though...

I was thinking of the same later last night... ;)

regards
 marcel

Re: [jr3 trade consistency for availability]

[Thomas Mueller <mu...@adobe.com>]

Hi,

>but in a distributed setup we cannot just use a simple counter.

I believe with vector clocks you can, see
http://en.wikipedia.org/wiki/Vector_clock

Regards,
Thomas

RE: [jr3 trade consistency for availability]

[Marcel Reutegger <mr...@adobe.com>]

> > I understand this would require tagging each node with a timestamp,
> >right?
>  > If that's the case, then it's not just about complexity, but also
> additional
>  > storage requirements.
> 
> If the node id is a counter, then there is no additional storage
> requirement.

but in a distributed setup we cannot just use a simple counter.
we'd have to find a way to partition the id (key) space and at
the same time make sure the complete id space is at least
partially ordered.

regards
 marcel

Re: [jr3 trade consistency for availability]

[Thomas Mueller <mu...@adobe.com>]

Hi,

> I understand this would require tagging each node with a timestamp,
>right?
 > If that's the case, then it's not just about complexity, but also
additional
 > storage requirements.

If the node id is a counter, then there is no additional storage
requirement.

Regards,
Thomas