You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Mubarak Seyed (Updated) (JIRA)" <ji...@apache.org> on 2012/01/12 02:29:40 UTC

[jira] [Updated] (HBASE-4720) Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server

     [ https://issues.apache.org/jira/browse/HBASE-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mubarak Seyed updated HBASE-4720:
---------------------------------

    Attachment: HBASE-4720.trunk.v3.patch

The attached file (HBASE-4720.trunk.v3.patch) contains changes for Andrew Purtell's code review comments.

This patch does not cover the following from Andrew's comments:

>The REST gateway does support a batch put operation, where the supplied model contains multiple rows. The request URI will contain the table name and a row key, but the row key would be ignored and should be set to something known not to exist, like "submit". (Row name in the model takes preference to whatever was supplied in the URI.) See RowResource, starting around line 160. This gives the client the option of submitting work in batch, to reduce overheads.

So optionally here you could retrieve a list of rows and process them, building a response that includes the disposition of each.

HTable.checkAndPut and HTable.checkAndDelete
API supports only one row at a time (http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/HTable.html#checkAndPut(byte[], byte[], byte[], byte[], org.apache.hadoop.hbase.client.Put)). I don't think we need to support batch of checkAndPut and checkAndDelete.

>The URI format for requests is '/<table>/<row>/ ...' This violates that by adding, just for check-and cases, a prefix. Having a special case like that should be avoided. What about handling this in TableResource, with a query parameter? '/<table>/<row>/?check' E.g.Then you won't need CheckAndXTableResource classes. Additionally use the appropriate HTTP operations. PUT/POST for check-and-put. DELETE for check-and-delete. The spec does not forbid bodies in DELETE requests. (I am unsure if Jetty/Jersey will support it however.)

We have discussed the design choices earlier (refer comments in the same JIRA), Stack and Ted have voted for option # 2 (/checkandput, /checkanddelete) option. If i have to go back to option #1 then i will have to re-work most of the stuff here.
                
> Implement atomic update operations (checkAndPut, checkAndDelete) for REST client/server 
> ----------------------------------------------------------------------------------------
>
>                 Key: HBASE-4720
>                 URL: https://issues.apache.org/jira/browse/HBASE-4720
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Daniel Lord
>            Assignee: Mubarak Seyed
>             Fix For: 0.94.0
>
>         Attachments: HBASE-4720.trunk.v1.patch, HBASE-4720.trunk.v2.patch, HBASE-4720.trunk.v3.patch, HBASE-4720.v1.patch, HBASE-4720.v3.patch
>
>
> I have several large application/HBase clusters where an application node will occasionally need to talk to HBase from a different cluster.  In order to help ensure some of my consistency guarantees I have a sentinel table that is updated atomically as users interact with the system.  This works quite well for the "regular" hbase client but the REST client does not implement the checkAndPut and checkAndDelete operations.  This exposes the application to some race conditions that have to be worked around.  It would be ideal if the same checkAndPut/checkAndDelete operations could be supported by the REST client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira