hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John de Roo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
Date Mon, 07 Jul 2014 09:17:34 GMT

    [ https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14053475#comment-14053475

John de Roo commented on HBASE-11447:

Version 0.3 attempts to address the following issues identified in the original.  If you think
I've missed something or not addressed it in the best way, please let me know.

Support for isolation level, read-only transactions and transaction timeout.
    Isolation levels are based on ANSI SQL, but does not address Snapshot isolation, MVCC
and the distinction with Lock Management.  It is assumed that MVCC support (without read lists)
equates to Read Committed and full Snapshot isolation (with read lists) equates to Repeatable
Reads.  However, it may be better to provide the ability to distinguish between MVCC/Snapshot
isolation and Lock Management - a concurrency control mode.  This would be provided in a similar
syntax to isolation level.

TransactionTable should match the signature of HTable and include all methods HTable supports.
    Added versions of all the HTable constructors with Transaction as a parameter.  Also provided
a setTransaction method so that TransactionTable methods match HTable.  This has some implications
for threading which are also described.

Removed resume and suspend.  
    They are not needed with streamTo and constructFrom.  Provided more information usage
including an example.

Added an iterator function.  See getAll.

Factory class.
    Several reviews identified the need for a factory class.  This is the one outstanding
issue not covered by the updated proposal.  I'm still working on the details.

Pseudo code/examples.
    Added a number of examples.

Added ability to override TM default values in hbase-site.xml file or equivalent.  Currently
only specifies the isolation level and transaction timeout, but I'm sure we need more here
to allow configuration of the Transaction Manager.

Rationalised exceptions including removing heuristics which really only apply to heterogeneous
2PC which is not supported by the proposal.

Changed the name of TransactionManager interface to TransactionServiceClient.

Kept the TransactionManager interface (now TransactionServiceClient) and the Transaction class
rather than combining the functions.  For example it would be possible to include both begin
and constructFrom methods as Transaction constructors, but we would still need a way to provide
the global/static methods.  I'm open to changing this if you have a better approach.

2PC interface.
  No 2PC interface (prepare/commit) is provided because this is an application API supporting
only a single TM.

Provided the option for read-only transactions.

Modified transaction timeout interface to be consistent with isolation level and transaction

Anything I've missed??

> Proposal for a generic transaction API for HBase
> ------------------------------------------------
>                 Key: HBASE-11447
>                 URL: https://issues.apache.org/jira/browse/HBASE-11447
>             Project: HBase
>          Issue Type: New Feature
>          Components: Client
>    Affects Versions: 1.0.0
>         Environment: Any.
>            Reporter: John de Roo
>            Priority: Minor
>              Labels: features, newbie
>             Fix For: 1.0.0
>         Attachments: Proposal for a common transactional API for HBase v0.3_1.pdf, Re
Proposal for a generic transaction API for HBase.htm
> HBase transaction management today is provided by a number of products, each implementing
a different API, each having different strengths.  The lack of a common API for transactional
interfaces means that applications need to be coded to work with a specific Transaction Manager.
 This proposal outlines an API which, if implemented by the different Transaction Manager
vendors would provide stability and choice to HBase application developers.  

This message was sent by Atlassian JIRA

View raw message