Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 7 Jul 2014 09:17:34 +0000 (UTC)
From: "John de Roo (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12724628.1404181551444.11046.1404724654239@arcas>
In-Reply-To: <JIRA.12724628.1404181551444@arcas>
References: <JIRA.12724628.1404181551444@arcas>
Subject: [jira] [Commented] (HBASE-11447) Proposal for a generic transaction
 API for HBase
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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 type.

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
(v6.2#6252)