[
https://issues.apache.org/jira/browse/PHOENIX-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14349317#comment-14349317
]
James Taylor commented on PHOENIX-1674:
---------------------------------------
Based on help from an internal discussion, I think I've been able to answer
this question:
bq. 2. What type of SQL isolation level supported by Tehpra? b) what about a
read of a piece of data that is then subsequently changed by another txn before
ours is committed?
If we stick to row level conflict detection, I think Tephra would map well to
the SQL expectations for snapshot isolation. For example, both of these queries
would work off of a consistent row snapshot:
{code}
UPDATE salary SET salary = salary * 1.1
UPDATE salary SET comp = bonus + salary * 1.1
{code}
If we did cell level conflict detection, then the latter would yield unexpected
results if bonus and/or salary were updated while this statement was executed.
With row level conflict detection, you'd get a optimistic concurrency exception
which would prevent any unexpected/inconsistent results.
As far as SQL isolation levels, that seems a little bit muddy. I don't think
we'd support a fully serializable isolation level, but I do think we'd support
this canonical definition (‘A Critique of ANSI SQL Isolation Levels’ by Gray et
al[1]).
bq. When the transaction T1 is ready to commit, it gets a Commit-Timestamp,
which is larger than any existing Start-Timestamp or Commit-Timestamp. The
transaction successfully commits only if no other transaction T2 with a
Commit-Timestamp in T1’s execution interval [Start-Timestamp, Commit-Timestamp]
wrote data that T1 also wrote. Otherwise, T1 will abort. This feature, called
First-committer-wins prevents lost updates (phenomenon P4). When T1 commits,
its changes become visible to all transactions whose Start-Timestamps are
larger than T1‘s Commit-Timestamp.
This write up is pretty good too:
http://en.wikipedia.org/wiki/Snapshot_isolation#Definition
[1] http://arxiv.org/pdf/cs/0701157.pdf
> Snapshot isolation transaction support through Tephra
> -----------------------------------------------------
>
> Key: PHOENIX-1674
> URL: https://issues.apache.org/jira/browse/PHOENIX-1674
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: James Taylor
>
> Tephra (http://tephra.io/ and https://github.com/caskdata/tephra) is one
> option for getting transaction support in Phoenix. Let's use this JIRA to
> discuss the way in which this could be integrated along with the pros and
> cons.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
