[
https://issues.apache.org/jira/browse/HBASE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603981#action_12603981
]
Clint Morgan commented on HBASE-669:
------------------------------------
I basically followed the original OCC paper with modifications for a
distributed commit protocol (because we have multiple parties involved). That
paper is available here:
http://www.seas.upenn.edu/~zives/cis650/papers/opt-cc.pdf
> The client runs the delete edits to invalidate the transaction?
No, we don't apply the edits until after the global commit decision has been
made. As they come into the regionserver they are WAL'ed and stored with the
transaction state until a commit.
> I don't get the global transaction log doohickey. Why not just have
> regionservers just discard COMMIT_PENDING if lease times out or on restart,
> comes across a COMMIT_PENDING replaying?
This is to handle the case where we voted to commit and then either
regionserver or the client dies. Its possible that the client told everyone
else to commit, so if we disregarded our part of the transaction the we loose
the AC from ACID.
+ We're trying to get zookeeper into the mix tout-de-suite. Then you wouldn't
have to do a custom server?
Yeah, that would be ideal.
> Why pass transaction state when doing scan/get reads?
We need this to check for conflicts. If we read a row that was later written
(in a transaction that committed in the meantime) the we have to abort the read
transaction.
> TransctionalState on server side should inherit from the client
> TransactionState? They have mostly same enums?
Yeah this probably makes sense.
Thanks for review.
> MultiRegion transactions with Optimistic Concurrency Control
> ------------------------------------------------------------
>
> Key: HBASE-669
> URL: https://issues.apache.org/jira/browse/HBASE-669
> Project: Hadoop HBase
> Issue Type: New Feature
> Components: client, ipc, regionserver
> Reporter: Clint Morgan
> Attachments: hbase-669-v2.patch, hbase-669.patch
>
>
> We have a need for ACID transactions across tables. This issue is about
> adding transactions which span multiple regions. We do not envision many
> competing writes, and will be read-dominated in general. This makes
> Optimistic Concurrency Control (OCC) seem like the way to go.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
