Jonathan, Yes, you are correct that setting the timestamps does not make the row writes atomic. However, the point I'm trying to make is that many people who say that they want atomic writes really want the data to reflect that they captured the data at time t(x) and that it is the same for both tables.
I believe you can still hold multiple individual locks on rows so you can synch the writes to be atomic, no? > From: [email protected] > To: [email protected] > Subject: RE: Time-series schema > Date: Sat, 30 Oct 2010 02:01:34 +0000 > > > > > > 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
