Return-Path: 
 <issues-return-12786-apmail-hbase-issues-archive=hbase.apache.org@hbase.apache.org>
X-Original-To: apmail-hbase-issues-archive@www.apache.org
Delivered-To: apmail-hbase-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 0D5DD6CB5
	for <apmail-hbase-issues-archive@www.apache.org>;
 Fri, 20 May 2011 10:00:29 +0000 (UTC)
Received: (qmail 47609 invoked by uid 500); 20 May 2011 10:00:28 -0000
Delivered-To: apmail-hbase-issues-archive@hbase.apache.org
Received: (qmail 47566 invoked by uid 500); 20 May 2011 10:00:28 -0000
Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@hbase.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@hbase.apache.org>
List-Post: <mailto:issues@hbase.apache.org>
List-Id: <issues.hbase.apache.org>
Delivered-To: mailing list issues@hbase.apache.org
Received: (qmail 47557 invoked by uid 99); 20 May 2011 10:00:28 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 May 2011 10:00:28 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 20 May 2011 10:00:27 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id D75F6D2E78
	for <issues@hbase.apache.org>; Fri, 20 May 2011 09:59:47 +0000 (UTC)
Date: Fri, 20 May 2011 09:59:47 +0000 (UTC)
From: "Tallat (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1588222752.30097.1305885587878.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <997026794.28792.1305845147389.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-3903) A successful write to client
 write-buffer may be lost or not visible
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/HBASE-3903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13036749#comment-13036749 ] 

Tallat commented on HBASE-3903:
-------------------------------

+1 on the patch, but I would suggest a couple of other things:

1) We can mention the same thing in section 10.1.2. "WriteBuffer and Batch Methods" for clarity, in <a href="book.html#client">client architecture</a>.

2) IMHO, the documentation at http://hbase.apache.org/acid-semantics.html has some weak points that need clarification, for example:

  (a) Visibility: <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>

      Here, what is a side channel exactly? 

  (b) Durability: <quote> All reasonable failure scenarios will not affect any of the guarantees of this document.</quote> 

    Here, what is a reasonable failure scenario?

Thanks.

> A successful write to client write-buffer may be lost or not visible
> --------------------------------------------------------------------
>
>                 Key: HBASE-3903
>                 URL: https://issues.apache.org/jira/browse/HBASE-3903
>             Project: HBase
>          Issue Type: Bug
>          Components: documentation
>         Environment: Any.
>            Reporter: Tallat
>            Assignee: Doug Meil
>            Priority: Minor
>              Labels: documentation
>         Attachments: acid-semantics_HBASE_3903.xml.patch
>
>
> A client can do a write to a client side 'write buffer' if enabled via hTable.setAutoFlush(false). Now, assume a client puts value v under key k. Two wrongs things can happen, violating the ACID semantics  of Hbase given at: http://hbase.apache.org/acid-semantics.html
> 1) Say the client fails immediately after the put succeeds. In this case, the put will be lost, violating the durability property:
> <quote> Any operation that returns a "success" code (eg does not throw an exception) will be made durable. </quote>
>  
> 2) Say the client issues a read for k immediately after writing k. The put will be stored in the client side write buffer, while the read will go to the region server, returning an older value, instead of v, violating the visibility property:
> <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,
> Tallat

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira