hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Yates (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4605) Add constraints as a top-level feature
Date Tue, 18 Oct 2011 05:16:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129495#comment-13129495
] 

Jesse Yates commented on HBASE-4605:
------------------------------------

@Ted: yeah, I found that wrapping. However, tracing the execution back up, a simple put (or
delete) ends up being called wrapped in a retry loop that tries the put every time a Throwable
is received. So we end up with a RetriesExhaustedException, rather than the original exception
being propagated back out.  The path down for the put was HTable.put->doPut->flushCommits->HConnectionMananger.processBatchOfPuts,
which does the retries. The end result is it takes minutes to do a commit because we are doing
this checking and retrying, rather than failing out as the CP docs would imply. I feel like
this could have serious impacts outside of this patch too..
Unless I'm missing something?
                
> Add constraints as a top-level feature
> --------------------------------------
>
>                 Key: HBASE-4605
>                 URL: https://issues.apache.org/jira/browse/HBASE-4605
>             Project: HBase
>          Issue Type: Improvement
>          Components: client, coprocessors
>    Affects Versions: 0.94.0
>            Reporter: Jesse Yates
>            Assignee: Jesse Yates
>         Attachments: java_Constraint_v2.patch
>
>
> From Jesse's comment on dev:
> {quote}
> What I would like to propose is a simple interface that people can use to implement a
'constraint' (matching the classic database definition). This would help ease of adoption
by helping HBase more easily check that box, help minimize code duplication across organizations,
and lead to easier adoption.
> Essentially, people would implement a 'Constraint' interface for checking keys before
they are put into a table. Puts that are valid get written to the table, but if not people
can will throw an exception that gets propagated back to the client explaining why the put
was invalid.
> Constraints would be set on a per-table basis and the user would be expected to ensure
the jars containing the constraint are present on the machines serving that table.
> Yes, people could roll their own mechanism for doing this via coprocessors each time,
but this would make it easier to do so, so you only have to implement a very minimal interface
and not worry about the specifics.
> {quote}

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

        

Mime
View raw message