[
https://issues.apache.org/jira/browse/HBASE-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058311#comment-14058311
]
John de Roo commented on HBASE-11447:
-------------------------------------
Thanks Shengzhe, good feedback.
1 & 2. I'll add more details to define the transaction states. I took them
from JTA. They could be rationalized for our use - we don't need
MARKED_ROLLBACK for example. However, I expect TMs will only provide those
states which it makes sense for them to report. I'll add a comment to that
effect. I don't want to remove them completely though because we really want
applications to be able to have some consistency regarding what is returned by
getStatus. It may be that transient states such as PREPARING are omitted by
some TMs or have different timing windows, but the application needs to be able
to tell the difference between the main states like ACTIVE, COMMITTING and
ROLLING_BACK in an implementation independent manner. The actual mapping
between a particular TMs internal states and these TransactionStatus values is
up to the TM to decide.
3. Did you want to remove the static keyword? I made all the methods static
after removing the begin transaction function from TransactionServiceClient and
also removed the factory method as the remaining methods are all global - we
don't need to instantiate a TransactionServiceClient for them. Perhaps you see
something here that I'm missing?
4. I agree with you here, I didn't put enough thought into moving the begin
methods out of the TransactionServiceClient interface into Transaction. I'll
change it to an abstract base class. It would be nice to do without the
parameters, but allowing a setter/getter approach would allow an application to
change or set things like isolation level and transaction type part-way through
a transaction which is very hard to implement at a TM level and could actually
cause problems - for example changing a write-read transaction to read-only or
moving to a higher isolation level.
5. I've used exceptions exclusively. Originally these where checked
exceptions, but I just changed them to unchecked, so returning a status on
rollback and commit might be a useful addition.
6. Good catch - I should have removed this method. It comes originally from
the JTA spec, but I decided it was unnecessary during a transaction - better to
set it on the begin. Originally I had the parameter defined as seconds, but
changed it to timeout to make the parameters easier to read. BTW seconds seems
very short for transaction timeouts - minutes might be a better metric. I'll
compromise and define a TransactionTimeout type (probably just int) and change
the parameter back to the unit - probably still seconds unless you think I
should change it.
7. Could you expand on this idea? I certainly agree that a byte array is a bit
basic.
8. Hmm, interesting. I'm not sure here whether I've confused you in the
document or, perhaps, I am. As I see it, a TransactionTable can only be
associated with a single transaction at any point in time. setTransaction
seems appropriate because it if setTransaction is called when the
TransactionTable is associated with a transaction, then the table becomes
associated with the new transaction and is disassociated with the prior
transaction. We have no nesting either as I wanted to keep the API as simple
as possible.
I know only a little about Themis. I took a look at the API to ensure that it
should be possible to map it to the proposal. It's an interesting approach
that I'd love to know more about. Are you based in the SF Bay Area? I'm there
for the next 2 weeks, and, if you're local, it would be great to get in touch.
I'll update the paper in the next few days, but there might be a little delay
as I'm travelling to the US on Sunday.
> 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)
