Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 24 Mar 2015 20:24:54 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12763496.1419354012000.13489.1427228694273@Atlassian.JIRA>
In-Reply-To: <JIRA.12763496.1419354012000@Atlassian.JIRA>
References: <JIRA.12763496.1419354012000@Atlassian.JIRA>
 <JIRA.12763496.1419354012824@arcas>
Subject: [jira] [Commented] (HBASE-12751) Allow RowLock to be reader writer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-12751?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D143=
78517#comment-14378517 ]=20

Enis Soztutar commented on HBASE-12751:
---------------------------------------

Makes sense. From my notes from 1 year ago:=20
{quote}
Different strategies for transactions depending on the type:=20

 Read-only    (get, scan)
 Write-only    (put)
 Read-Write  (increment, append, row processor)

Current transaction models
Current model for write only transactions
1. lock the rows=20
2. update latest timestamps
3. get mvcc number
  3.1. sync writeQueue
  3.2. increment write number
  3.3. add trx to the writeQueue
4. Insert to memstore (with mvcc number)
5. AppendNoSync() to WAL
  5.1. obtain seq_num
  5.2. append entry to pendingWrites (our own linked list buffer)
6. Release row locks
7. sync WAL
  7.1. hlogflush (append pending writes to hdfs buffer)
  7.2. increase sync point
8. Complete memstore insert
  8.1. sync writeQueue
  8.2. mark write completed.
  8.3. advanceMvcc number as much as possible (from the writeQueue). Notify=
 all waiters
  8.4. wait for mvcc read number to advance past our mvcc write number

Current model for read only transactions
1. Obtain mvcc read number
2. Perform scans with that mvcc number=20

Current model for read-write transactions (increment)
1. lock the row=20
2. get an mvcc number, wait for all transaction to finish before this numbe=
r=20
3. get mvcc number
4. Do the reads for the transaction, compute writes for the transaction. Al=
ways use current time=20
5. Insert to a temporary memstore
6. AppendNoSync() to WAL
7. Insert to memstore
8. Release row locks
9. sync WAL
10. Complete memstore insert

Current model for read-write transactions (processRowsWithLocks)
1. lock the rows
2. Do the reads for the transaction, compute writes for the transaction (Ro=
wProcessor)
3. get mvcc write number
4. Insert to memstore
5. AppendNoSync() to WAL
6. Release row locks
7. sync WAL
8. Complete memstore insert

Note, there is no waiting for all trx to finish after acquiring row locks (=
bug?)


Observations:=20
  - Write-only trxs do not need the row lock. Pure writes can be serialized=
 with mvcc or seq_num=E2=80=99s.=20
  - Read-only trxs should be kept as is for performance (use mvcc)=20
  - Read-write trxs can conflict with other read-write trx / or write trasa=
ctions
{quote}

We do not need row locks for conflict resolution for write-only transaction=
s, but we still need locking for conflicts between read-write and read-writ=
e/write only transactions. Doing shared locks should help with this. We are=
 optimizing for write-only transactions at the expense of read-write transa=
ctions (which today have to wait for ALL transactions that started before i=
ts start time to finish).=20

> Allow RowLock to be reader writer
> ---------------------------------
>
>                 Key: HBASE-12751
>                 URL: https://issues.apache.org/jira/browse/HBASE-12751
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Elliott Clark
>            Assignee: Elliott Clark
>         Attachments: HBASE-12751-v1.patch, HBASE-12751.patch
>
>
> Right now every write operation grabs a row lock. This is to prevent valu=
es from changing during a read modify write operation (increment or check a=
nd put). However it limits parallelism in several different scenarios.
> If there are several puts to the same row but different columns or stores=
 then this is very limiting.
> If there are puts to the same column then mvcc number should ensure a con=
sistent ordering. So locking is not needed.
> However locking for check and put or increment is still needed.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)