[jira] [Comment Edited] (HBASE-11447) Proposal for a generic transaction API for HBase

["Ted Yu (JIRA)" <ji...@apache.org>]

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

Ted Yu edited comment on HBASE-11447 at 7/8/14 5:03 AM:
--------------------------------------------------------

w.r.t. exception classes, it would be nice if they have common base class which is not Exception.
{code}
public class IllegalStateException extends Exception
{code}
IllegalStateException is defined by Java.
{code}
public class RollbackException extends Exception
{code}
Maybe name the above RolledBackException ?
{code}
<name>hbase.transaction.isolationlevel</name>
<value>2</value>
{code}
Would it be better if symbolic names are used to specify isolation levels ? That way users doesn't need to look up the numeric value for the isolation level they want.
For 5.1:
{code}
txSC = new TransactionServiceClient(conf);
Configuration config = HBaseConfiguration.create();
{code}
'config' should be used for constructing TransactionServiceClient.

For 5.3,
bq. The concurrency control method (locking or MVCC) and isolation level will have no effect on this because both puts are performed within the same transaction.
What's the background for the use case described in 5.3 ? Such usage would result in indeterministic outcome when commit is called, right ?

bq. Should the TransactionServiceClass contain the begin and constructFrom methods or should these be constructors for the Transaction class?
Looks like constructFrom method should belong to Transaction class.


was (Author: yuzhihong@gmail.com):
w.r.t. exception classes, it would be nice if they have common base class which is not Exception.
{code}
public class IllegalStateException extends Exception
{code}
IllegalStateException is defined by Java.
{code}
public class RollbackException extends Exception
{code}
Maybe name the above RolledBackException ?
{code}
<name>hbase.transaction.isolationlevel</name>
<value>2</value>
{code}
Would it be better if symbolic names are used to specify isolation levels ? That way users doesn't need to look up the numeric value for the isolation level they want.
For 5.1:
{code}
txSC = new TransactionServiceClient(conf);
Configuration config = HBaseConfiguration.create();
{code}
'config' should be used for constructing TransactionServiceClient.

For 5.3,
bq. The concurrency control method (locking or MVCC) and isolation level will have no effect on this because both puts are performed within the same transaction.
What's the background for the use case described in 5.3 ? Such usage would result in indeterministic outcome when commit is called, right ?

bq. Should the TransactionServiceClass contain the begin and constructFrom methods or should these be constructors
for the Transaction class?
Looks like constructFrom method should belong to Transaction class.

> 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)