hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: checkAndPut fails when using lock - HBASE-6725
Date Tue, 11 Sep 2012 01:34:30 GMT
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

As for this specific issue, should we just document this more prominently?

-- Lars

----- Original Message -----
From: Nicolas ThiƩbaud <ni.thiebaud@gmail.com>
To: dev@hbase.apache.org
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

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:


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.

View raw message