Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - checkAndPut fails when using lock - HBASE-6725


Copy link to this message
-
Re: checkAndPut fails when using lock - HBASE-6725
lars hofhansl 2012-09-11, 01:34
Client controlled locks are (somewhat) broken in HBase. For example these locks will not survive a split or a move of a region to a different region server.
We had a thread about this a while ago. My comment then was to deprecate client driven locks altogether.
As for this specific issue, should we just document this more prominently?

-- Lars
----- Original Message -----
From: Nicolas Thiébaud <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc:
Sent: Monday, September 10, 2012 3:00 PM
Subject: checkAndPut fails when using lock - HBASE-6725

Hello devs,

When calling checkAndPut concurrently with a previously held lock, several
client threads may successfully mutate the value. This is due to
checkAndMutate that reuses the lock provided by the client (even if the
lock isn't on the mutated row) although several requests may be racing with
the same lock (see: Integer getLock(Integer lockid, byte [] row, boolean
waitForLock)).

I believe there are 2 solutions:
a. Use some sort of internal lock, which requires a specific lock set for
check and mutate methods
b. Consider CAP with locks as bad usage and deprecate the feature

I've opened a jira here for that matter:
https://issues.apache.org/jira/browse/HBASE-6725

Nicolas.

---------------------------------------------------------------------------------
For the record, here is my use case of CAP + locks:

A part of my application uses hbase to generate ids from labels using CAP
and here is the workflow:

1. lock row label
2. CAP(row = proposedId, qual = "value", value = label, expectedValue null) if fails retry with next proposedId
3. put(row = label, qual = "id", value = id)
4. release lock

Since we are generating user readable ids, proposedId may be equal to
label, and in that case I need to use the held lock in step 2. Therefore
CAP doesn't request a lock and can allow several client threads that
provide a lock (that aren't necessarily on the mutated row) to create my id.

A solution to my problem would be to have getLock check if the lockId
corresponds to the mutated row, but it isn't a solution to the general case.