hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John de Roo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11447) Proposal for a generic transaction API for HBase
Date Tue, 08 Jul 2014 12:16:07 GMT

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

John de Roo commented on HBASE-11447:

Hi Ted, more great feedback!  

seconds parameter is now timeout (still in seconds though of course).
I've renamed streamTo to toByteArray.
I've removed all the transaction related constructors from TransactionTable.
The intention was that calling setTransaction when a TransactionTable has an active transaction
associated with it would change the active transaction associated with the TransactionTable.
 This allows the TransactionTable object to be reused for subsequent transactions.  I've added
a comment to explain this in the text.
Changed TransactionTable to TransactionTableInterface.
I've changed "in parallel" to "at the same time".  I think it clarifies the relationship.
Added a TransactionServiceClient.getSupportedIsolationLevels to return supported isolation
Added a TransactionException class and derived all the exceptions from it.  Also derived from
RuntimeException to make all exceptions unchecked.
Changed IlegalStateException to IllegalTransactionStateException.
Changed RollbackException to RolledBackException.
Changed to symbolic names for the isolation level property.
Fixed the order of new TransactionServiceClient and HBaseConfiguration.create in the examples.
>From 5.3 (concurrency control method): This is perhaps a bad example.  The point is that
because both threads are performing work against the same transaction, concurrency control
mechanisms don't apply.  At least, that's my experience.  If anyone's aware of TMs which provide
protection/serialization in this circumstance, I'll happily change the text and adjust the
specification to allow for it.
I'll move both begin and constructFrom to Transaction constructors.  This cleans up the concerns
about transactional operations being in the wrong place.
It's 12am now, so I guess I won't get the updated spec out until morning now - I have a bit
of cleanup to do flow the changes through the whole document.
I should also take some time to learn the text formatting notation for comments! 8^)

> 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

View raw message