conditional atomic operations

["Yakubovich, Alexey" <Al...@searshc.com>]

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.

Re: conditional atomic operations

[Vladimir Rodionov <vl...@gmail.com>]

It is worth taking look at:
https://issues.apache.org/jira/browse/HBASE-10390

-Vlad

On Tue, Jan 26, 2016 at 11:26 AM, Yakubovich, Alexey <
Alexey.Yakubovich@searshc.com> wrote:

> 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.
>