[
https://issues.apache.org/jira/browse/HIVE-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874898#comment-13874898
]
Brock Noland commented on HIVE-5843:
------------------------------------
bq. In the places where they were taking more than one argument or returning
values I've put in structs.
Thank you very much!!
bq. But a number of the calls take a single long value, the transaction id. I
don't want to wrap and unwrap this all the time, as I'd like this to be as fast
as possible and it seems overkill.
Sorry Alan, please excuse me for my ignorance. From HIVE-5317 "Agreed, this
will fail badly in a one insert at a time situation.". Therefore do we see
these methods being called in tight loops? It seems that the IO in this
situation would dominate any unwrapping of objects?
bq. The odds that methods like abortTransaction() will take more than a
transactionId seem low.
Please know that I am not trying to be obstinate here! :) My only concern is
that we follow best practices for new thrift APIs. The number of times I have
heard "we won't need to change X" and then X later needed to be changed is too
numerous to count.
API's always evolve and therefore I would suggest that every method take a
single parameter and return a single response. Additionally I would not throw
an exceptions as they are problematic as well and instead return a Status
struct (code, message, stacktrace) which can contain an optional stack trace
should an exception be thrown on the server side.
> Transaction manager for Hive
> ----------------------------
>
> Key: HIVE-5843
> URL: https://issues.apache.org/jira/browse/HIVE-5843
> Project: Hive
> Issue Type: Sub-task
> Affects Versions: 0.12.0
> Reporter: Alan Gates
> Assignee: Alan Gates
> Fix For: 0.13.0
>
> Attachments: HIVE-5843-src-only.patch, HIVE-5843.2.patch,
> HIVE-5843.3-src.path, HIVE-5843.3.patch, HIVE-5843.patch,
> HiveTransactionManagerDetailedDesign (1).pdf
>
>
> As part of the ACID work proposed in HIVE-5317 a transaction manager is
> required.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
