Currently, it's not on our list of things to do. There are a number
of reasons why it would be better to use Zookeeper here than to try
and build it into HBase.
That said, I think you could get everything you need if you tried
Zookeeper, using that to acquire locks on the row you need a
transaction on. It's supposedly very high performance and supports
your use case precisely.
-Bryan
On May 10, 2008, at 11:52 PM, Zhou Wei wrote:
Bryan Duxbury 写道:
startUpdate is deprecated in TRUNK. Also, it doesn't do what you
are thinking it does. Committing a BatchUpdate is atomic across
the whole row, however. There is currently no way to make a get
and a commit transactional, though there is an issue open for
write-if-not-modified-since support. If this is something you need
we can talk about how it might be supported.
Thanks for answering my questions.
So currently HBase is not suitable for transactional web applications.
A simple counting transaction can not work by concurrent accesses:
transaction{
get(x);
x++;
write(x);
}
In my opinion, "write-if-not-modified-since" support may not be the
best idea of implement single-row transaction.
Because if write can not be performed, application has to try again
and again, or just return error and leave user to choose again or
abort.
Probably locking, waiting and scheduling at region server might be
preferable in this case.
Is the single-row transaction feature currently in the roadmap of
HBase?
Zhou
-Bryan
On May 7, 2008, at 7:48 PM, Zhou Wei wrote:
Hi
Does HBase support single-row transaction as described in
Bigtable paper?
"Bigtable supports single-row transactions, which can be
used to perform atomic read-modify-write sequences on
data stored under a single row key." --Bigtable paper
If so, how can I define a transaction in HBase,
is it looks like this:
lid=startUpdate
get(lid)
..
put(lid)
...
commit(lid)
Are these transactions isolated with each other?
If not, is there a way to achieve that?
Thanks
Zhou
