[
https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14495477#comment-14495477
]
Chris Westin commented on DRILL-2782:
-------------------------------------
I'll bet that tools expect commit() to work because they may want that to
release a read-only transaction's timestamp if the databases they target
support point-in-time-consistent read-only transactions. It might be better to
let those commits to go through, but for us to complain (in the server) if the
parser detects any attempt to perform a mutating DML (insert, update, or
delete).
But really, I'd check with the tools first to decide either way. Do they issue
commits, even if no mutations have been done? That's what will matter.
> 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)
>
> 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)
