[
https://issues.apache.org/jira/browse/DRILL-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654246#comment-14654246
]
Daniel Barclay (Drill) commented on DRILL-2560:
-----------------------------------------------
*Workaround:*
A workaround that should work in all cases is to make sure that, for any
{{executeQuery(...)}} call that it makes, client code calls {{next()}} (on the
returned {{ResultSet}}) until {{next()}} returns false (or throws an exception)
before it calls {{executeQuery(...)}} again.
That should ensure that a query started earlier has finished executing before a
query started later begins to execute.
(If you only need to make sure that the first query is not canceled by
beginning the second query, and don't need the first query to complete before
the second query begins, you can execute the queries using separate Statement
objects.)
> JDBC execute calls return asynchronously for DDLs
> -------------------------------------------------
>
> Key: DRILL-2560
> URL: https://issues.apache.org/jira/browse/DRILL-2560
> Project: Apache Drill
> Issue Type: Bug
> Components: Client - JDBC
> Affects Versions: 0.8.0
> Reporter: Chris Westin
> Assignee: Daniel Barclay (Drill)
> Fix For: 1.3.0
>
>
> While working with TestViews, I noticed that JDBC's executeQuery() returns
> immediately for drop view statements. For DDLs, users' expectation would be
> that the call would return synchronously. The same would be true for
> execute(), and executeUpdate(), if used for DDLs. This behavior is pretty
> typical for RDBMSs. This avoids the user having to consume the (non-)output
> in order to wait for the statement to complete -- otherwise it will get
> cancelled when the Statement is closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
