[
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:
{code}
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"));
....
{code}
>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:
{quote}
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.
{quote}
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:
{code}
void put(Put put) throws IOException;
{code}
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
(v6.2#6252)
