[
https://issues.apache.org/jira/browse/HBASE-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13204055#comment-13204055
]
Todd Lipcon commented on HBASE-5311:
------------------------------------
bq. should 'state' be closed before being updated?
I don't think it matters from a correctness standpoint. If we close the old
state before updating the state variable, then all concurrent accessors
beginning at this point will sit and spin while any previously running
accessors finish their work. If we set the new state first, then any new
accessors can immediately proceed so we don't cause any "hiccup" in access.
The semantics of this whole data structure are a little subtle though so we'll
have to be careful to expose only a minimal API and clearly document where we
might have strange causality relations, etc.
> Allow inmemory Memstore compactions
> -----------------------------------
>
> Key: HBASE-5311
> URL: https://issues.apache.org/jira/browse/HBASE-5311
> Project: HBase
> Issue Type: Improvement
> Reporter: Lars Hofhansl
> Attachments: InternallyLayeredMap.java
>
>
> Just like we periodically compact the StoreFiles we should also periodically
> compact the MemStore.
> During these compactions we eliminate deleted cells, expired cells, cells to
> removed because of version count, etc, before we even do a memstore flush.
> Besides the optimization that we could get from this, it should also allow us
> to remove the special handling of ICV, Increment, and Append (all of which
> use upsert logic to avoid accumulating excessive cells in the Memstore).
> Not targeting this.
--
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
