hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas ThiƩbaud <ni.thieb...@gmail.com>
Subject checkAndPut fails when using lock - HBASE-6725
Date Mon, 10 Sep 2012 22:00:38 GMT
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message