-RE: How to implement this check put and then update something logic?
Thanks, seems there are no other better solution?
Really need a "GetAndPut" atomic op here ...
> You can do this by looping over a checkAndPut operation until it succeeds.
> On Thu, May 9, 2013 at 8:52 PM, Liu, Raymond <[EMAIL PROTECTED]>
> > Any suggestion?
> >> Hi
> >> Say, I have four field for one record :id, status, targetid, and count.
> >> Status is on and off, target could reference other id, and
> >> count will record the number of "on" status for all targetid from same id.
> >> The record could be add / delete, or updated to change the status.
> >> I could put count in another table, or put it in the same
> >> table, it doesn't matter. As long as it can work.
> >> My question is how can I ensure its correctness of the "count"
> >> field when run with multiple client update the table concurrently?
> >> The closet thing I can think of is checkAndPut, but I will need
> >> two steps to find out the change of count, since checkAndPut etc can
> >> only test a single value and with EQUAL comparator, thus I can only
> >> check upon null firstly, then on or off. Thus when thing change
> >> during this two step, I need to retry from first step until it succeed. This
> could be bad when a lot of concurrent op is on going.
> >> And then, I need to update count by checkAndIncrement, though
> >> if the above problem could be solved, the order of -1 +1 might not be
> >> important for the final result, but in some intermediate time, it
> >> might not reflect the real count of that time.
> >> I know this kind of transaction is not the target of HBASE, APP
> >> should take care of it, then , what's the best practice on this? Any
> >> quick simple solution for my problem? Client RowLock could solve this
> >> issue, But it seems to me that it is not safe and is not recommended and
> >> Btw. Is that possible or practice to implement something like
> >> PutAndGet which put in new row and return the old row back to client been
> >> That would help a lot for my case.
> >> Best Regards,
> >> Raymond Liu