You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@omid.apache.org by "Francisco Perez-Sorrosal (JIRA)" <ji...@apache.org> on 2017/03/04 00:32:45 UTC

[jira] [Commented] (OMID-58) Snapshot isolation violation in read only transactions

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

Francisco Perez-Sorrosal commented on OMID-58:
----------------------------------------------

Hey [~ohads]. There's no need to go to the TSO as we can do it from the Client side. I started working on a fix for this in the past but I stopped cause I realized that it would be better do first some refactoring to improve how we manage the pre/post hooks for the AbstractTM and remove the TransactionException from the interface exposed to the users. Anyways, I've put in here the draft of what I did:  https://github.com/francisco-perez-sorrosal/incubator-omid/commit/2990ea706735a2b7f980c96cd266b174c5ab3133

The round-trip to the database could be avoided if we store the LWM in ZK and we put a watcher in the client, but this could potentially create more problems.


> Snapshot isolation violation in read only transactions
> ------------------------------------------------------
>
>                 Key: OMID-58
>                 URL: https://issues.apache.org/jira/browse/OMID-58
>             Project: Apache Omid
>          Issue Type: Bug
>            Reporter: Ohad Shacham
>
> Read only transactions in snapshot isolation cannot conflict with any other transaction. Therefore, the commit process does not contact the TSO and mark the transaction as committed.
> This can cause to snapshot isolation violation in cases where the coprocessor deletes information from HBase that changes the snapshot of an inflight read only transaction t. t in this case will be marked as committed, even thought it did not read a consistent snapshot.
> t would be aborted if the commit process would contact the tso because its read timestamp is smaller than the low water mark.
> A solution for this would be to contact the TSO, check the low water mark, identify in the requestProcessor that the transaction is read only, and immediately return a result using the reply processor. This will reduce the latency (v.s. the regular flow) of read only transactions, while maintaining snapshot isolation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)