hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "cuijianwei (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
Date Fri, 11 Jul 2014 07:38:06 GMT

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

cuijianwei commented on HBASE-11447:

Thanks for this proposal, it's cool.
1. Is it necessary to provide init(final ClusterConnection connection, ExecutorService pool)
and destroy() in TransactionServiceClient? Transaction API might be used together with HTable(some
tables need transaction while others only need direct HTable access) in application program,
it might be necessary to share global ClusterConnection or ExcecutorService between Transaction
API and HTable. For destroy(), it could provide a change to clean up global resources. For
example, if the TransactionServiceClient implementation needs to visit a remote server, users
might expect to invoke TransactionServiceClient.destroy() to clean up Rpc resources when the
program exiting.
2. How about pass Configuration to the constructor of Transaction and let Transaction provide
a getter method as [~lhofhansl] commented, such as getTable(String tableName), then the example
code from 5.2 of v0.4_1 could be:
private static TransactionTable txTable;
Configuration config = HBaseConfiguration.create();
Transaction tx1 = new Transaction(config);
TransactionTable txTable = tx1.getTable("table1");
Put p1 = new Put(Bytes.toBytes("row1"));
>From the proposal, it seems that the Transaction need to hold the mutations, transaction
state and do commit logic, while TransactionTable tends to only provide access methods. From
this point, Transaction might need more configurable options which could be specified by Configuration
in constructor.
3. In 3.4 of v0.4_1:
If no Transaction is associated with a TransasctionTable, it operates identically to HTable.
That is non-transactionally.
For example, a put method call will be passed through to HTable.put.
What about throwing Exception in this situation? Users might forget to set Transaction for
TransactionTable in their code, if they run the code, unexpected data might be written to
HBase directly by HTable(The data format might be different between Transaction of HTable).
It might be more safe to throw Exception in this context because users create TransactionTable
explicitly to do the Transaction. 
4. What about make TransactionException extends IOException? Then, the Transaction API will
perform more similar as HTable.

[~ipodfans], Thank you for mentioning Themis. I am thinking of changing themis to support
API in the proposal. It seems that themis could implement the proposed APIs without modifying
the core logic:). One question is that TransactionTableInterface will extend HTableInterface,
then users could methods defined in HTableInterface such as:
  void put(Put put) throws IOException;
However, users should not specify timestamp or version in put when using themis as transaction
implementation because these attributes are used internally. It is feasible to throw Exception
when user setting timestamp or version in put and issue to themis Transaction. I just wonder
is there a better way to avoid users do such things? 

> 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, Proposal
for a common transactional API for HBase v0.4_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