Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Tue, 14 Apr 2015 23:08:59 +0000 (UTC)
From: "Daniel Barclay (Drill) (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.12820884.1429033836000.2436.1429052939761@Atlassian.JIRA>
In-Reply-To: <JIRA.12820884.1429033836000@Atlassian.JIRA>
References: <JIRA.12820884.1429033836000@Atlassian.JIRA>
 <JIRA.12820884.1429033836698@arcas>
Subject: [jira] [Assigned] (DRILL-2782) Decide, implement behavior for
 transaction-related JDBC methods
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DRILL-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Barclay (Drill) reassigned DRILL-2782:
---------------------------------------------

    Assignee: Daniel Barclay (Drill)

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