[
https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Barclay (Drill) updated DRILL-2782:
------------------------------------------
Description:
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).
was:
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 (that is, Drill).
In turn, that means that it is not clear exactly what Drill's JDBC driver's
transaction-related methods should do. ,
[IN PROGRESS--Why the heck does Jira intercept some magic keystroke and submit
things without confirmation?!]
> 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)
>
> 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)
