You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "James Taylor (JIRA)" <ji...@apache.org> on 2017/08/24 18:13:00 UTC

[jira] [Resolved] (PHOENIX-4119) Upsert uses timestamp of server holding table metadata

     [ https://issues.apache.org/jira/browse/PHOENIX-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Taylor resolved PHOENIX-4119.
-----------------------------------
    Resolution: Duplicate

With PHOENIX-4089 (which will be part of upcoming 4.12 release), Phoenix uses the latest timestamp when writing data. I'd recommend you synchronize your clocks in your cluster, though.

> Upsert uses timestamp of server holding table metadata
> ------------------------------------------------------
>
>                 Key: PHOENIX-4119
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4119
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.8.0
>            Reporter: Mark Christiaens
>
> When doing an upsert, I noticed that the resulting put-command to HBase uses a timestamp obtained from the server managing the corresponding table's metadata (cfr. https://issues.apache.org/jira/browse/PHOENIX-1674?focusedCommentId=14349982&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14349982).  
> Now, if the row that is updated resides on a second server, that second server could have some clock skew.  After the upsert, if you fetch that updated row without specifying an explicit query timestamp, then you might not see the effects of the upsert until the second server's clock has caught up with the first server's clock.
> I think that the desired behavior is that the puts performed occur with a timestamp derived from the region server where their rows are stored.  (Of course, that still leaves the problem of region migration from one server to the next but it's a step in the right direction).  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)