[
https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques Nadeau updated DRILL-2782:
----------------------------------
Fix Version/s: 1.1.0
> 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)
> Fix For: 1.1.0
>
> Attachments: DRILL-2782-1Hygiene.3.patch.txt,
> DRILL-2782-2Core.3.patch.txt, DRILL-2782-2Core.4.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
(v6.3.4#6332)
