[
https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14054045#comment-14054045
]
Ted Yu commented on HBASE-11447:
--------------------------------
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)
