[
https://issues.apache.org/jira/browse/HBASE-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651615#action_12651615
]
Jonathan Gray commented on HBASE-1014:
--------------------------------------
Epoch timestamps have no concept of timezone, they are all according to GMT.
So that should not be an issue.
Having said that, I've expressed my dislike for setting stamps clientside.
We're already asking users to synchronize their server clocks, now the client
clocks must also be synchronized.
The only gain we would have from setting it clientside is so the client can be
aware of the stamp. However, in a vast majority of use cases this is
unnecessary. I have no issue with allowing an optional client-specific stamp,
but feel strongly that we should not be requiring or depending on the client
setting of stamps. We may get new functionality but it seems almost certain
that people would run into problems.
My vote would be to wait for 880 and allow an optional setting of stamp with
the new API.
> commit(BatchUpdate) method should return timestamp
> ---------------------------------------------------
>
> Key: HBASE-1014
> URL: https://issues.apache.org/jira/browse/HBASE-1014
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Slava
> Fix For: 0.19.0
>
>
> The commit(BatchUpdate) and commit(list<BatchUpdate>) should return timestamp
> that BatchUpdate was committed with (in the case of commit(list<BatchUpdate>
> should return array of timestamps).
> This should reduce number of round trips and improve performance in update
> operations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
