[
https://issues.apache.org/jira/browse/HBASE-12672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14244781#comment-14244781
]
Andrew Purtell commented on HBASE-12672:
----------------------------------------
Thinking on this a bit more:
{quote}
bq. only once the edit is applied on the secondary we make it visible in the
primary
How does that work when HBase clients, upon returning from a write, do and
should expect to read their own writes immediately?
{quote}
It would be strange, but we could make clients aware of the special aspect of
the table, thus advising them the nature of reality has changed, and let them
(i.e. the HBase client library) build synchronous semantics on top: write
something, then spin until the last written edit becomes visible, then return
control back to the application. We'd need to ensure the sink reliably acks
edits and checks that the source acked the ack, and retransmit acks if not, for
reliable signal delivery for making "pending" edits visible.
> Support optionally replicating a table synchronously
> ----------------------------------------------------
>
> Key: HBASE-12672
> URL: https://issues.apache.org/jira/browse/HBASE-12672
> Project: HBase
> Issue Type: Improvement
> Reporter: James Taylor
> Priority: Minor
>
> Sometimes a table may contain state in which it's crucial to know that
> replication occurred before continuing with the update. Though this would
> mean that you'd block updates to this table if your secondary cluster was
> unavailable, that might be a tradeoff that a user would be willing to make.
> An example would be in support of SQL sequences. See this thread
> (http://s.apache.org/fTP) and PHOENIX-1422 for more discussion and context.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
