[
https://issues.apache.org/jira/browse/OMID-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644676#comment-16644676
]
ASF GitHub Bot commented on OMID-90:
------------------------------------
Github user ohadshacham commented on a diff in the pull request:
https://github.com/apache/incubator-omid/pull/46#discussion_r223975170
--- Diff:
hbase-client/src/main/java/org/apache/omid/transaction/SnapshotFilterImpl.java
---
@@ -181,22 +179,44 @@ public CommitTimestamp locateCellCommitTimestamp(long
cellStartTimestamp, long e
// 2) Then check the commit table
// If the data was written at a previous epoch, check whether
the transaction was invalidated
- Optional<CommitTimestamp> commitTimeStamp =
commitTableClient.getCommitTimestamp(cellStartTimestamp).get();
- if (commitTimeStamp.isPresent()) {
- return commitTimeStamp.get();
+ boolean invalidatedByOther = false;
+ Optional<CommitTimestamp> commitTimestampFromCT =
commitTableClient.getCommitTimestamp(cellStartTimestamp).get();
+ if (commitTimestampFromCT.isPresent()) {
+ if (isLowLatency && !commitTimestampFromCT.get().isValid())
+ invalidatedByOther = true;
+ else
+ return commitTimestampFromCT.get();
}
// 3) Read from shadow cell
- commitTimeStamp =
readCommitTimestampFromShadowCell(cellStartTimestamp, locator);
+ Optional<CommitTimestamp> commitTimeStamp =
readCommitTimestampFromShadowCell(cellStartTimestamp, locator);
if (commitTimeStamp.isPresent()) {
return commitTimeStamp.get();
}
+ // In case of LL, if found invalid ct cell, still must check
sc in stage 3 then return
+ if (invalidatedByOther) {
+ assert(!commitTimestampFromCT.get().isValid());
+ return commitTimestampFromCT.get();
+ }
+
// 4) Check the epoch and invalidate the entry
// if the data was written by a transaction from a previous
epoch (previous TSO)
- if (cellStartTimestamp < epoch) {
+ if (cellStartTimestamp < epoch || isLowLatency) {
boolean invalidated =
commitTableClient.tryInvalidateTransaction(cellStartTimestamp).get();
if (invalidated) { // Invalid commit timestamp
+
+ // If we are running lowLatency Omid, we could have
manged to invalidate a ct entry,
+ // but the committing client already wrote to shadow
cells:
--- End diff --
This can happen only in low latency mode, since in the regular mode the
client keeps the commit table entry if persisting the commit was done after the
tso lost its lease.
> Reducing begin/commit latency by distributing the write to the commit table
> ---------------------------------------------------------------------------
>
> Key: OMID-90
> URL: https://issues.apache.org/jira/browse/OMID-90
> Project: Apache Omid
> Issue Type: Sub-task
> Reporter: Ohad Shacham
> Assignee: Yonatan Gottesman
> Priority: Major
> Attachments: OmidCloud-VLDB.pdf, omid90.patch
>
>
> Today, Omid's commits are done by the transaction manager. In order to
> efficiently write to the commit table, the transaction manager batches these
> writes. This optimization, even thought reduces the write time to HBase,
> significantly increases the begin and commit latency. The commit latency
> increases since a commit operation returns only after its commit timestamp
> was persisted in the commit table. And the begin latency increases since
> begin returns a transaction id that is also used by the transaction to
> identify its snapshot and therefore, begin returns only after all commits
> with commit id smaller than the begin id was persisted in the commit table.
> This is crucial, since a snapshot change during a transaction run may violate
> snapshot isolation.
>
> The idea of this feature is to distribute the commit by moving the write to
> the commit table from the server to the client. The transaction manager does
> conflict analysis and returns a commit timestamp. While the client atomically
> persists this commit in the commit table.
> This significantly reduces the begin and commit latency, since batching is
> not required anymore. A begin operation can immediately returns and a commit
> operation returns after conflict detection.
> This can introduce snapshot isolation violation since a slow client can
> commit and change other transaction's snapsho. Therefore, we use an
> invalidation technique which is similar to the one Omid uses today to
> maintain snapshot isolation in high availability mode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
