hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10354) Add an API for defining consistency per request
Date Fri, 31 Jan 2014 22:42:11 GMT

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

Enis Soztutar commented on HBASE-10354:
---------------------------------------

bq. +1 on above... TIMELINE or STALE or STALE_ALLOWED?
I'll rename to TIMELINE. 
bq. Do we have to have a pb and java enum? Maybe for the client API but does it have show
up on the server? Can it just be pb enum on server.
We need two enums for the client side. We cannot expose the PB to the client. In server side,
Consistency is only accessed through a Get or Scan object. So in places where we can expose
PB get and scan objects, we can equally go with PB version of consistency. 
bq. This has to be public?
I can see Result.setExists() which is exposed. The PB version of Result does not have the
stale parameter, because we were setting it from the client side because we know the RPC went
to a replica. But I think we should carry it over the PB Result as well. We might still need
setStale() for PB -> POJO conversion though. 
bq. This going into a branch?
Yes, these will go into the branch. 
bq. what we doing, for 3 versions v1, v2, v3, a reader can see something like v3, v2, v1:
by going first on the primary, then on a secondary with a less recent version, then on another
secondary with the oldest version. What we guarantee is that at a point all the clients will
see v3, but until this point is reached, everything can happen?
Yes indeed. I'll reword that javadoc. The guarantee is on the server side, rather than on
the client side. If you are sticking to a server you will always see transactions in order,
but if you are jumping from server to server (like in the failover RPC implementation) then
there are no guarantees within different secondary replicas. We can implement further guarantees
if we do pipelined writes and ordered requests to replicas, but not in the first cut. 



> Add an API for defining consistency per request
> -----------------------------------------------
>
>                 Key: HBASE-10354
>                 URL: https://issues.apache.org/jira/browse/HBASE-10354
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Client
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.99.0
>
>         Attachments: hbase-10354_v1.patch
>
>
> We should add an API to be able to define the expected consistency level per operation.
This API should also allow to check whether the results coming from a query (get or scan)
is stale or not. The defaults should reflect the current semantics. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message