Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (athena.apache.org: domain of saint.ack@gmail.com
 designates 209.85.216.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=NtbsQ5G/St56/zfzTyzB6ExsIMqRZAsA5rMN7rDHcKybIizsqWUUCHrXoQ4fSMctas
         Jd2288ZXKU9opnlxOA93V6XgoUwD34oIkmecJMpYFmBBHOS9l9yWQaqpJNpCuVF6EPTz
         efH0k4i/lwt1YTN5ZYGcIUi9zSbdDXesjnVMY=
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <BANLkTin_QYGr0HKuSyQubMni7zuGct8D1g@mail.gmail.com>
References: <BANLkTi=1QjGFBXPHQjn_0=O8+YrGMzbxXw@mail.gmail.com>
	<BANLkTinaS6J=4dx6dhAHaU_ZoYSQDfgVJg@mail.gmail.com>
	<BANLkTin3a-kFLRyCXk9rFq3BVGL_dZJN2g@mail.gmail.com>
	<BANLkTimpKG0BhxuAn4v42wMX=JafWjO3GA@mail.gmail.com>
	<BANLkTin_QYGr0HKuSyQubMni7zuGct8D1g@mail.gmail.com>
Date: Thu, 19 May 2011 15:06:30 -0700
Message-ID: <BANLkTikgRRoHXRJ91YtiZLGCPKvQkOxoRg@mail.gmail.com>
Subject: Re: Reading from client buffer
From: Stack <stack@duboce.net>
To: dev@hbase.apache.org, fazoolmein@gmail.com
Cc: Jean-Daniel Cryans <jdcryans@apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Mind filing an issue referring to this conversation Fazool?  Thanks.  St.Ack

On Thu, May 19, 2011 at 2:49 PM, Fazool <fazoolmein@gmail.com> wrote:
> Agreed.
>
> On Thu, May 19, 2011 at 11:15 PM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:
>
>> You would still have "confirmed" writes that may never get to the
>> server, which comes back to my point that the buffer shouldn't be used
>> in this case.
>>
>> J-D
>>
>> On Thu, May 19, 2011 at 1:56 PM, Fazool <fazoolmein@gmail.com> wrote:
>> > 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 <jdcryans@apache.org
>> >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 <fazoolmein@gmail.com>
>> 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
>> >> >
>> >>
>> >
>>
>