hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amitanand Aiyer (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5414) Assign different memstoreTS to different KV's in the same WALEdit during replay
Date Thu, 16 Feb 2012 21:56:59 GMT

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

Amitanand Aiyer commented on HBASE-5414:
----------------------------------------

@Stack. Yes. That is the current behavior.

What we are trying to get is to see if we can provide  a semantics where .... the client is
able to specify the order in which the operations are applied. (This is already the case wrt
the implementation, because we loop through the mutations in the AtomicRowMutation and apply
them one by one -- in the same order in which they were applied.)

So, part 1) seems to have been automatically addressed. Except for the corner race-condition
which we will need to fix, so scans/gets do not see a partial application of a AtomicRowMutation.


                
> Assign different memstoreTS to different KV's in the same WALEdit during replay
> -------------------------------------------------------------------------------
>
>                 Key: HBASE-5414
>                 URL: https://issues.apache.org/jira/browse/HBASE-5414
>             Project: HBase
>          Issue Type: Sub-task
>          Components: client, coprocessors, regionserver
>            Reporter: Amitanand Aiyer
>             Fix For: 0.94.0
>
>         Attachments: HBASE-5414.D1749.1.patch
>
>
> HBASE-5203 combines all the different Puts/Deletes into one WALEdit. This is
> required to ensure that we persist the atomic mutation in its enterity and not
> in parts.
> When combined into a single WALEdit, we create one big familyMap that is a combination
> of all the family maps in the mutations. The KV's in this familyMap have no information
> about memstoreTS (it is not yet assigned).
> However, when we apply the mutations to the Memstore (if there are no failures) we end
up
> incrementing the memstoreTS for each operation. 
> This can lead to the client seeing different order of operations -- depending on weather
or
> not there was a RS crash/restart.

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