[ 
https://issues.apache.org/jira/browse/OMID-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644679#comment-16644679
 ] 

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_r223973121
  
    --- 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
    --- End diff --
    
    Please add this comment: "This check is not needed in a non low latency 
mode, since during post commit, the client keeps the entry in the commit table 
when 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)

Reply via email to