[
https://issues.apache.org/jira/browse/HBASE-18643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amit Patel updated HBASE-18643:
-------------------------------
Description:
In [HBASE-14070|https://issues.apache.org/jira/browse/HBASE-14070] and
[HBASE-18642|https://issues.apache.org/jira/browse/HBASE-18642], we discuss
using HLC and deprecating the client from being able to set timestamps for
mutations. However, one important use case for setting the timestamps (which
represent transaction IDs) is for transactions. What we could do is add a
transaction ID to the result object that is the hybrid logical timestamp of a
particular batch operation. The transaction ID should be considered opaque and
clients should not make assumptions for how the ID is changed.
This change would be similar to the way Couchbase uses HLC where the timestamp
of a mutation (denoted CAS) is stored in the result and sent back to the client.
was:
In [HBASE-14070|https://issues.apache.org/jira/browse/HBASE-14070] and
[HBASE-18642|https://issues.apache.org/jira/browse/HBASE-18642], we discuss
using HLC and deprecating the client from being able to set timestamps for
mutations. However, one important use case for setting the timestamps (which
represent transaction IDs) is for transactions. What we could do is add a
transaction ID to the result object that is the hybrid logical timestamp of a
particular batch operation.
The transaction ID should be considered opaque and clients should not make
assumptions for how the ID is changed.
> Add 'Transaction ID' to Result for HLC
> --------------------------------------
>
> Key: HBASE-18643
> URL: https://issues.apache.org/jira/browse/HBASE-18643
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Amit Patel
> Assignee: Amit Patel
> Priority: Minor
>
> In [HBASE-14070|https://issues.apache.org/jira/browse/HBASE-14070] and
> [HBASE-18642|https://issues.apache.org/jira/browse/HBASE-18642], we discuss
> using HLC and deprecating the client from being able to set timestamps for
> mutations. However, one important use case for setting the timestamps (which
> represent transaction IDs) is for transactions. What we could do is add a
> transaction ID to the result object that is the hybrid logical timestamp of a
> particular batch operation. The transaction ID should be considered opaque
> and clients should not make assumptions for how the ID is changed.
> This change would be similar to the way Couchbase uses HLC where the
> timestamp of a mutation (denoted CAS) is stored in the result and sent back
> to the client.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
