[
https://issues.apache.org/jira/browse/HBASE-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661084#action_12661084
]
Michael Gottesman commented on HBASE-1090:
------------------------------------------
So I went through it and found the issue. The problem that seemed to be
happening had to do with me returning false in the middle of the checkAndSave
in HRegion/releasing locks in the middle of the checkAndSave in HRegion.
Instead of doing that, I created a variable that just said whether or not the
expected values matched up and then if it doesn't skips the save part of check
and save. Then in the typical HBase fashion the locks are released and a value
is returned after all of the try blocks have closed.
Attached is the new patch.
> Atomic Check And Save in HTable
> -------------------------------
>
> Key: HBASE-1090
> URL: https://issues.apache.org/jira/browse/HBASE-1090
> Project: Hadoop HBase
> Issue Type: New Feature
> Reporter: Michael Gottesman
> Priority: Minor
> Attachments: 1090v3.patch, 1090v4.patch, hbase-1090.patch,
> hbase-1090v2.patch
>
>
> Check And Save is a simple operation where one gives both a BatchUpdate with
> updates and a Map mapping columns to expected values (byte[] -> byte[]). The
> operation works as follows:
> 1. Server gets locks on row.
> 2. Server checks that the actual values of the specified columns match the
> given expected values
> 3. If False, return False, if True update the row
> 4. Unlock row.
> Pretty simple... but useful.
> Included in the attached patch are the necessary updates for HTable,
> HRegionServer, RegionServerInterface, and HRegion. I also added a small unit
> test to HTable where the test checks that checkAndSave succeeds when the
> expected values line up and fail when the values are different.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
