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] [Comment Edited] (DRILL-2782) Decide, implement behavior for transaction-related JDBC methods
Date Thu, 23 Apr 2015 20:33:38 GMT

    [ 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:32 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, the current resolution also includes overriding SQLLine's default level to be TRANSACTION_NONE
in Drill's sqlline wrapper scripts.


was (Author: dsbos):
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, 

> 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)

Mime
View raw message