atom feed18 messages in org.apache.hadoop.hbase-userRe: Use of versions in transaction an...
FromSent OnAttachments
stackJun 16, 2009 10:23 pm 
Bradford StephensJun 16, 2009 10:33 pm 
Andrew PurtellJun 17, 2009 1:44 am 
jason hadoopJun 17, 2009 4:32 am 
Jean-Daniel CryansJun 17, 2009 5:19 am 
llpindJun 17, 2009 2:34 pm 
Ryan RawsonJun 17, 2009 2:36 pm 
llpindJun 17, 2009 2:43 pm 
stackJun 17, 2009 3:46 pm 
llpindJun 18, 2009 9:33 am 
Jim Kellerman (POWERSET)Jun 18, 2009 9:40 am 
stackJun 18, 2009 10:22 am 
llpindJun 18, 2009 2:35 pm 
stackJun 18, 2009 2:40 pm 
llpindJun 18, 2009 9:20 pm 
stackJun 18, 2009 10:40 pm 
Bria...@nokia.comJun 21, 2009 9:30 am 
Andrew PurtellJun 21, 2009 10:32 am 
Subject:Re: Use of versions in transaction and replication strategies
From:Andrew Purtell (
Date:Jun 21, 2009 10:32:09 am

Hi Brian,

One discussion I am aware of related to replication. The question was should
there be effort put into edit conflict resolution by tracking the causal
ordering of edits, e.g. by way of using vector clocks or similar techniques, or
is that even necessary given Bigtable's inherent multiversioning. Either
technique pushes the task of conflict resolution up to the client, but the
latter is "inline" with Bigtable's data model and conventional API, and the
implementation effort is therefore lower and the complexity of the resulting
replication model is more simple, an important consideration (easier to
demonstrate correctness, etc.). It is true that if clients are setting the
timestamp dimension to user defined values, then an edit on one cluster may
conflict with an edit written to another, with the conflict "resolved" from the
client perspective as if by arbitrary coin toss.

- Andy

________________________________ From: "" <> To: Sent: Sunday, June 21, 2009 9:30:39 AM Subject: Use of versions in transaction and replication strategies

Hi all,

Not too long ago their were some discussions related to implementing
transactions and/or replication strategies that made use of column versions. I
can't remember whether the discussions happened in this forum or in one or more
Jira tickets. Regardless, my question is whether there will indeed be a reliance
on cell versions to implement either of these features. I ask because currently,
the API allows the caller to decide what value is used for the version stamp.
It doesn't have to be a timestamp. In fact, some folks have talked about not
even using versions as versions, but rather as an additional data dimension.

So my question really boils down to whether HBase would need to restrict the use
of versions if versions were indeed used to implement transactions and/or