[
https://issues.apache.org/jira/browse/HBASE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clint Morgan updated HBASE-669:
-------------------------------
Attachment: hbase-669-v2.patch
Current version:
Added StressTestTransactions which tries to do a lot of conflicting
transactions. This was useful in finding some subtle issues with
synchronization and the commit protocol, and gives me some confidence that
everything is working properly.
still TODO:
- integrate with regionserver's WAL
- come up with global transaction log solution. This log is only read when
there has been a failure during the commit process: Regionservers are holding a
COMMIT_PENDING transaction (they voted to commit, but have not heard the final,
global solution) and never hear back the client. Or a regionserver crashes,
restarts, looks at his WAL and sees entries for a transaction, but no final
decision (commit or abort).
I have a simple interface for the transaction logger client, and I'm
considering implementations in hdfs, zookeeper, or a specialized transaction
server backed by hdfs. A pure hdfs implementation is attractive because it
requires no additional infrastructure/servers, however performance will not be
good as we will just be writing lots of small, short lived files. (All we need
is ability to get unique transactionId's, and map between transactionId's and
transaction state)
So now I'm leaning toward a special-purpose server which could run alongside
the master...
> 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.
