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

Amruth S commented on HIVE-18338:
---------------------------------

Kindly check this.

> [Client, JDBC] Expose async interface through hive JDBC.
> --------------------------------------------------------
>
>                 Key: HIVE-18338
>                 URL: https://issues.apache.org/jira/browse/HIVE-18338
>             Project: Hive
>          Issue Type: Improvement
>          Components: Clients, JDBC
>    Affects Versions: 2.3.2
>            Reporter: Amruth S
>            Assignee: Amruth S
>            Priority: Minor
>              Labels: pull-request-available
>         Attachments: HIVE-18338.patch, HIVE-18338.patch.1, 
> HIVE-18338.patch.2, HIVE-18338.patch.3
>
>
> Lot of users are struggling and rewriting a lot of boiler plate over thrift 
> to get pure asynchronous capability. 
> The idea is to expose operation handle, so that clients can persist it and 
> later can latch on to the same execution.
> *Problem statement*
> Hive JDBC currently exposes 2 methods related to asynchronous execution
> *executeAsync()* - to trigger a query execution and return immediately.
> *waitForOperationToComplete()* - which waits till the current execution is 
> complete *blocking the user thread*.
> This has one problem
> If the client process goes down, there is no way to resume queries although 
> hive server is completely asynchronous.
> *Proposal*
> If operation handle could be exposed, we can latch on to an active execution 
> of a query.
> *Code changes*
> Operation handle is exposed. So client can keep a copy.
> latchSync() and latchAsync() methods take an operation handle and try to 
> latch on to the current execution in hive server if present



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to