Another way would be that when you read, check the write buffer. If it is a hit, flush the buffer, and then return the read.
This way, bulk loads will still work, and occasionally, we might have a slower read. On Thu, May 19, 2011 at 9:14 PM, Jean-Daniel Cryans <[email protected]>wrote: > The write buffer is a hack for faster write performance during bulk > loads, no one should use it in a situation like you described. > > Even if the client was able to read from it's own buffer, the edits > didn't make it to the region server so the other clients wouldn't be > able to see that new data either. Now let's suppose the client died > before flushing, well you would be serving data that actually never > existed! > > I think we should just fix the documentation. > > J-D > > On Thu, May 19, 2011 at 8:02 AM, fazool mein <[email protected]> wrote: > > Hi, > > > > I am going through the Hbase code to understand its properties better. > > > > There is something called 'write buffer' on the client side. Say it is > > enabled. Now, assume a client puts value v under key k, and immediately > > reads k. > > > > As I understand from the code, the put will be stored in the client side > > write buffer, while the read will go to the region server, returing an > older > > value, instead of v. > > > > Doesn't this violate the ACID semantics (visibility in particular ) of > Hbase > > given at: http://hbase.apache.org/acid-semantics.html > > > > <quote> > > > > When a client receives a "success" response for any mutation, that > mutation > > is immediately visible to both that client and any client with whom it > later > > communicates through side channels. > > > > </quote> > > > > Thanks. > > > > Regards > > >
