[
https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14509582#comment-14509582
]
Daniel Barclay (Drill) edited comment on DRILL-2782 at 4/23/15 8:31 PM:
------------------------------------------------------------------------
Trying to have setTransactionIsolation(...) throw an exception if the caller
tries to set the transaction isolation level to any isolation value other than
Connection.TRANSACTION_NONE (to try to reflect that fact that Drill isn't
transactional) caused SQLLine to emit an "Error: " line, since SQLLine tries to
set the isolation level to TRANSACTION_REPEATABLE_READ even if the user hasn't
request that (via command-line parameters or SQLLine commands).
Therefore,
was (Author: dsbos):
Note: Trying to have setTransactionIsolation(...) throw an exception if the
caller tries to set the transaction isolation level to any isolation value
other than Connection.TRANSACTION_NONE (to try to reflect that fact that Drill
isn't transactional) causes SQLLine to emit an "Error: " line, since SQLLine
tries to set the isolation level to TRANSACTION_REPEATABLE_READ even if the
user hasn't request that (via command-line parameters or SQLLine commands).
> 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.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)
