Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 15 Oct 2011 04:24:12 +0000 (UTC)
From: "Todd Lipcon (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1728479482.16664.1318652652434.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1807178936.16833.1318287989766.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4570) Scan ACID problem with concurrent
 puts.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon commented on HBASE-4570:
------------------------------------

bq. I thought that (a) ARFU requires that its target be volatile still, and (b) that the point of lazySet was to allow cheaper writes, with no effect on reads.

I don't think it requires a volatile target - it just treats the target as having part of the volatile semantics for the particular update in question. The trick here would be that we don't need an up-to-date read whenever we read the field in order for lazy initialization to work. If a second thread recomputes the same array copy, that's fine. We only need to make sure that the writes happen in the correct order (ie the reference to the byte array isn't published before the byte array itself has been copied)
                
> Scan ACID problem with concurrent puts.
> ---------------------------------------
>
>                 Key: HBASE-4570
>                 URL: https://issues.apache.org/jira/browse/HBASE-4570
>             Project: HBase
>          Issue Type: Bug
>          Components: client, regionserver
>    Affects Versions: 0.90.1, 0.90.3
>            Reporter: Jonathan Hsieh
>         Attachments: 4570-instrumentation.tgz, hbase-4570.tgz, hbase-4570.txt
>
>
> When scanning a table sometimes rows that have multiple column families get split into two rows if there are concurrent writes.  In this particular case we are overwriting the contents of a Get directly back onto itself as a Put.
> For example, this is a two cf row (with "f1", "f2", .. "f9" cfs).  It is actually returned as two rows (#55 and #56). Interestingly if the two were merged we would have a single proper row.
> Row row0000024461 had time stamps: [55: keyvalues={row0000024461/f0:data/1318200440867/Put/vlen=1000, row0000024461/f0:qual/1318200440867/Put/vlen=10, row0000024461/f1:data/1318200440867/Put/vlen=1000, row0000024461/f1:qual/1318200440867/Put/vlen=10, row0000024461/f2:data/1318200440867/Put/vlen=1000, row0000024461/f2:qual/1318200440867/Put/vlen=10, row0000024461/f3:data/1318200440867/Put/vlen=1000, row0000024461/f3:qual/1318200440867/Put/vlen=10, row0000024461/f4:data/1318200440867/Put/vlen=1000, row0000024461/f4:qual/1318200440867/Put/vlen=10}, 
> 56: keyvalues={row0000024461/f5:data/1318200440867/Put/vlen=1000, row0000024461/f5:qual/1318200440867/Put/vlen=10, row0000024461/f6:data/1318200440867/Put/vlen=1000, row0000024461/f6:qual/1318200440867/Put/vlen=10, row0000024461/f7:data/1318200440867/Put/vlen=1000, row0000024461/f7:qual/1318200440867/Put/vlen=10, row0000024461/f8:data/1318200440867/Put/vlen=1000, row0000024461/f8:qual/1318200440867/Put/vlen=10, row0000024461/f9:data/1318200440867/Put/vlen=1000, row0000024461/f9:qual/1318200440867/Put/vlen=10}]
> I've only tested this on 0.90.1+patches and 0.90.3+patches, but it is consistent and duplicatable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira