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,
CompareFilter.CompareOp<https://archive.cloudera.com/cdh5/cdh/5/hbase/devapidocs/org/apache/hadoop/hbase/filter/CompareFilter.CompareOp.html>
compareOp,
byte[] value,
Put<https://archive.cloudera.com/cdh5/cdh/5/hbase/devapidocs/org/apache/hadoop/hbase/client/Put.html>
put)
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 as
(pid:String, hits:int)
I want the update only happens if the new value for the field hits is grater
that the current value.
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
Alexey
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.
