hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Kellerman (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HBASE-798) Provide Client API to explicitly lock and unlock rows
Date Fri, 08 Aug 2008 02:14:46 GMT

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

jimk edited comment on HBASE-798 at 8/7/08 7:13 PM:
-------------------------------------------------------------

<removing extra text from original comment>

> Jonathan Gray - 07/Aug/08 05:41 PM
> I'm going to work on another patch now which adds a kind of "upsert/increment" functionality.
I have a few
> particular and frequent use cases in mind that others may have a need for. Rough APIs
below...
> incrementColumnValue(table,row,family:column) -> Reads last value at column (must
be family:column), 

<snip>
Shouldn't this work be targeted at HBASE-493 ?

Or link this patch to HBASE-493, saying that the patch for this issue is included in the patch
for this issue.

      was (Author: jimk):
    Jonathan Gray - 07/Aug/08 05:41 PM
I'm going to work on another patch now which adds a kind of "upsert/increment" functionality.
I have a few particular and frequent use cases in mind that others may have a need for. Rough
APIs below...

incrementColumnValue(table,row,family:column) -> Reads last value at column (must be family:column),
increments it, and writes new column version with incremented value (wrapped in a single row
lock for atomicity)

columnWithIncrementedValue(table,row,family,newcolumn) -> This may be more limited to others,
but we have many ordered column families where every column value inserted is lexicographically
smaller than all previous (always inserted to the top). The value within each column is an
incremented value. This grabs the value of the top column in the family, increments it, and
uses it as the value for the newcolumn to be inserted at the top. There will be no checking
for newcolumn being smaller (lexicographically) than the last one, this is the responsibility
of the client, but this is assumed for correctness.

incrementColumn(table,row,family) -> This is also specialized. We assume a schema where
a family has only one column. We read that column value, increment it, add the new column
(reusing the old columns value), delete the old column, release the lock, return the new incremented
column to the client. This is a way to provide a check-out mechanism for incrementing identifiers.

I'm going to build this patch on top of the previous patch because some helper functions and
classes will be useful.
[ Show ยป ]
> Jonathan Gray - 07/Aug/08 05:41 PM
> I'm going to work on another patch now which adds a kind of "upsert/increment" functionality.
I have a few
> particular and frequent use cases in mind that others may have a need for. Rough APIs
below...
> incrementColumnValue(table,row,family:column) -> Reads last value at column (must
be family:column), 

<snip>
Shouldn't this work be targeted at HBASE-493 ?

Or link this patch to HBASE-493, saying that the patch for this issue is included in the patch
for this issue.
  
> Provide Client API to explicitly lock and unlock rows
> -----------------------------------------------------
>
>                 Key: HBASE-798
>                 URL: https://issues.apache.org/jira/browse/HBASE-798
>             Project: Hadoop HBase
>          Issue Type: New Feature
>          Components: client, ipc, regionserver
>            Reporter: Jonathan Gray
>            Priority: Minor
>         Attachments: hbase-798-v1.patch
>
>
> We need to be able to perform a series of reads from and writes to a single row without
any potential interference from other clients.
> Unfortunately this is a bit involved because normal reads currently do not acquire row
locks, so it requires adding additional get/getRow calls that obtain and release a row lock.
> In addition, there will be two additional client calls, lockRow/unlockRow, which actually
acquire and release the locks.  Though each lock is associated with an HRegion, this will
be tracked within the HRegionServer.  When a lock is acquired from the client, it is handled
much like a Scanner.  We obtain the row lock from the HRegion, store the region name and lock
identifier in a synchronized Map, and also obtain a lease to ensure that the lock will eventually
be released even if the client dies.
> This also required adding a RowLockListener (implements LeaseListener) private class
in HRS to handle row lock lease expiration.
> HRS.lockRow will return a long lockId (as openScanner does) that will be used in subsequent
client calls to reuse this existing row lock.  These calls will check that the lock is valid
and perform the operations without any locking  (wrappers around get*, new versions of batchUpdate,
openScanner, etc).
> This is going to really add some noise to the list of available HTable/client methods
so I'm not sure if it's something people would want to commit into a normal release.  Regardless
this does provide some very convenient functionality that may be useful to others.
> We are also looking into Clint Morgan's HBASE-669, but one major downside is that there
is a significant amount of overhead involved.  This row locking is already built in and this
will only extend the API to allow clients to work with them directly.  There is little to
no overhead at all.  The only (obvious) performance consideration is that this should only
used where necessary as rows will not be locked and unlocked as quickly with round-trip client
calls.  In our design, we will have specific notes in our schema about which tables (or even
which families or columns) must be accessed with row locks at all times and which do not.
> This is my first attempt at adding any additional functionality, so comments, criticism,
code reviews are encouraged.
> I should have a patch up tomorrow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message