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

Phabricator commented on HBASE-5414:
------------------------------------

aaiyer has commented on the revision "HBASE-5414 [jira] Assign different 
memstoreTS to different KV's in the same WALEdit during replay".

INLINE COMMENTS
  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:2842 Agreed.


  Keeping track of the timestamp might be tricky.We could bump up the 
memstoreTS for every KV that we see. this will resolve the contention between 
Put/Put as well. The current approach does not.

  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:2856 Kind of 
.... This is to increment the memstoreTS across *different* WALEdits.

  The one inside the loop is incremented when we see different types within the 
*same* WALEdit.

REVISION DETAIL
  https://reviews.facebook.net/D1749

                
> 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

        

Reply via email to