> 
> > There is no such atomicity provided by HBase. Recent TableIndexed may
> help,
> > but I have not personally tried it.
> >
> >
> 
> Uhm actually there is. :-)
> 
> Like I said in the other post, when you insert the rows, you can fetch
> the local time on the node and use it when you insert the row as the
> time stamp for the row.
> So you can get an 'atomic' write.
> 
> Just a word of advice. Make sure you use the right System method. Had a
> developer accidentally use nanoTime() and now you have rows in a table
> that don't make sense...
> 
> 

Using the same timestamp does not make the writes to different rows atomic.

Atomic generally means that in addition to something seeming to appear at the 
same instant, the entire thing must be successful or none of it at all.  That 
is really a critical element of atomic and why you need some type of 
transactions or transaction log.  A client that does two separate Put 
operations on two different rows can fail at any point.  The existing 
TableIndexed implementation used OCC (optimistic concurrency control) and 
allowed for things to be undone if an operation failed.

There should be some new work around indexing using Coprocessors in the next 
few months.  I'm excited about the prospects there.  Rather than the OCC 
approach, I'm thinking more like asynchronous, eventually consistent secondary 
indexing.

JG

Reply via email to