hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yakubovich, Alexey" <Alexey.Yakubov...@searshc.com>
Subject conditional atomic operations
Date Tue, 26 Jan 2016 19:26:25 GMT
I notices an unanswered question: “Check and Put method used with
a long)”.  I would like to ask it in a slightly different form:
Can you customize (within reasonable restrictions)) the
condition for the atomic update?

The HTable method

        checkAndPut(byte[] row,
  byte[] family,
  byte[] qualifier,
  byte[] value,

Uses the CompareFilter.CompareOp enum. But what I would like is the complete customization
of compareOp, with my own logic.

And still, can you apply the existing checkAndPut with compareOp on a field that contains
integer, or long, of my own class (in binary form)? (and naturally I need GREATER be in context
of java.lang.Integer, not binary strings that represent integers).

Or, if not, how to solve the following use case:

Several spark executors updating the data structurer (in HBase table) that contains record

(pid:String, hits:int)

I want the update only happens if the new value for the field hits is grater that the current
Now suppose one of executors (E1) has a new value (V1) for the given pid. If it operates non-atomically
 it could read current value V0, compare with new value and tries to update (if V1 > V0).
But it could happen that current value was already been increased to V2 by another executor.
The E1 knows the prev. value and could use regular checkAndPut, so that update would not happen
if current value was changed, but E1 still does’t know if new value (V1) is bigger than
updated current value (V2), and and has no way but to attempt the same update again… (if
V1 >V2).

I hope I described the use case clearly, it seems very typical and elementary one. Can somebody
please hint how to solve it?
Thank you

This message, including any attachments, is the property of Sears Holdings Corporation and/or
one of its subsidiaries. It is confidential and may contain proprietary or legally privileged
information. If you are not the intended recipient, please delete it without reading the contents.
Thank you.

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