hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray" <jl...@streamy.com>
Subject RE: HBase concurrent access and BatchUpdate obj
Date Wed, 06 Aug 2008 19:02:45 GMT

That could also work for the simple case.  Exposing the row locks allows us
to do anything we want "within a row transaction" so to speak; many reads,


I will probably work up an additional patch to add an increment insert which
does the second method I described earlier.  I think this is actually might
be a common enough use case that others would want it as well.


-----Original Message-----
From: Chris Richard [mailto:chris.richard@gmail.com] 
Sent: Wednesday, August 06, 2008 11:47 AM
To: hbase-user@hadoop.apache.org
Subject: Re: HBase concurrent access and BatchUpdate obj

I filed HBASE-493 a while back, which is a request for
Write-If-Not-Modified-Since support. I believe is often termed 'optimistic
concurrency control'.

>>From https://issues.apache.org/jira/browse/HBASE-493:

Client retrieves cell (or row) and stores timestamp.

Client writes to same cell (or row) and passes timestamp.
If the cell's (or row's) latest timestamp matches the passed timestamp, the
write succeeds. If the timestamps do not match, the write fails and the
client is notified (exception?). The client must re-retrieve the cell/row to
get the latest timestamp before attempting to write back.

This behavior would be optional, if the client doesn't pass a timestamp to
the write method, no modified check would be enforced.
Just something to consider - it may or may not be easier than exposing a
locking mechanism.

On Wed, Aug 6, 2008 at 9:02 AM, Jonathan Gray <jlist@streamy.com> wrote:

> Jean-Adrien,
> Interesting timing of your post.
> I just filed HBASE-798 last night
> (https://issues.apache.org/jira/browse/HBASE-798), Provide Client API to
> explicitly lock and unlock rows.
> This feature that I'm currently working on would expose the existing row
> locking system used internally within HBase.  This would provide you with
> mechanism to: lock the row, get the current column value, increment and
> write the new value, unlock the row.
> Currently simple reads _do not_ row lock, so if you wanted to protect this
> particular table/family/column/whatever you would need to also make every
> read through a new version that did obtain a lock on the row every time.
> Another option for you (if you only have this one very particular use case
> of incrementing a column) would be to write this "increment column value"
> as
> a new client method internal to HBase that could just handle this lock,
> read, write, unlock.  I have a sophisticated caching layer on top of HBase
> including custom queries like joins/merges/nots/etc so we're heavy on
> application level logic.  Exposing the locks to our code allows us to do
> all
> this logic in our own code.
> And a final option would be using an external locking system, as you
> mentioned, but for something this simple I don't think that's necessary.
> Jon
> -----Original Message-----
> From: Jean-Adrien [mailto:adv1@jeanjean.ch]
> Sent: Wednesday, August 06, 2008 3:54 AM
> To: hbase-user@hadoop.apache.org
> Subject: HBase concurrent access and BatchUpdate obj
> Hello,
> I just read the message about concurrent access in this mailing list
> .net%3e
> and I just want to verify this:
> If I use the future new version of hbase, i.e. 0.2.0 which enables the
> BatchUpdate objects.
> All my update are made in an atomic way. Ok. But there is no lock
> to avoid write-after-write fault, if, for example, I would like to have a
> code like: ( If havn't found the 0.2.0 api online, so its just pseudo code
> )
> // load a cell from hbase
> Cell c = table.get("row", "column_family:column");
> // make some computation with the cell content
> int oldValue = Integer.parseInt(c.getContent());
> int newValue = oldValue + 1;
> // update the cell
> BatchUpdate bu = new BatchUpdate(c);
> c.setContent(String.valueOf(newContent));
> bu.commit();
> That is, take the current value of a cell, update it in a
> toward cell content, and save it.
> I guess there is NO mechanism ensuring that another client that runs the
> same code as the same time, got the same value for the cell than me and
> increments it. It means that rather than having cell value sequence 1 -> 2
> -> 3 -> 4 it takes the values 1 -> 2 -> 2 -> 3.
> Am I right ?
> Should a lock mechanism be provided to the user through another system
> ZooKeeper or is it in the goal of hbase to provide such lock system ?
> Thanks a lot.
> Have a nice day
> --
> View this message in context:
> Sent from the HBase User mailing list archive at Nabble.com.

View raw message