drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Barclay (Drill) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DRILL-2782) Decide, implement behavior for transaction-related JDBC methods
Date Fri, 17 Apr 2015 06:21:59 GMT

     [ https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Daniel Barclay (Drill) updated DRILL-2782:
    Attachment: DRILL-2782-2Core.2.patch.txt

> Decide, implement behavior for transaction-related JDBC methods
> ---------------------------------------------------------------
>                 Key: DRILL-2782
>                 URL: https://issues.apache.org/jira/browse/DRILL-2782
>             Project: Apache Drill
>          Issue Type: Bug
>            Reporter: Daniel Barclay (Drill)
>            Assignee: Daniel Barclay (Drill)
>         Attachments: DRILL-2782-1Hygiene.2.patch.txt, DRILL-2782-2Core.2.patch.txt
> Officially, JDBC requires transaction support. Because of that, the JDBC specification
(PDF document and Javadoc) addresses the behavior of transaction-related methods only for
the case in which transactions are supported.
> In particular, JDBC does not specify the behavior when transactions are not supported.
> Therefore, it is not clear what behavior a JDBC client tool would expect, or be programmed
to handle, from a JDBC driver and back end that do not support transactions (i.e., Drill).
> In turn, that means that it is not clear exactly what Drill's JDBC driver's transaction-related
methods should do. 
> For example, if a tool tries to call setAutoCommit(false), issue a create-view query,
and call commit():
> - Should Drill throw an exception at setAutoCommit(false) (because Drill's behavior,
which is effectively auto-commit mode, can't be disabled)?  If so, would tools likely be able
to handle that exception, specifically, by switching to using auto-commit mode, not calling
commit() after the query? 
> - Should Drill silently accept the setAutoCommit(false) even though it can't really implement
it?  If so, should it silently accept the commit(), to make things look "normal" to calling
tools? If so, then what about a call to rollback()? 
> One datapoint: We've seen Spotfire call setAutoCommit(false), issue a query, and call
rollback() (presumably to make sure to avoid making unintended changes).

This message was sent by Atlassian JIRA

View raw message