[DRILL-2782] Decide, implement behavior for transaction-related JDBC methods

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.1.0
• Assignee: Daniel Barclay
• Reporter: Daniel Barclay
• Created: 14/Apr/15 17:50
• Updated: 01/Jul/15 01:01
• Resolved: 27/Apr/15 19:39

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

Issue Links

• supercedes: DRILL-2445 JDBC : Connection.rollback method currently throws UnsuportedOperationException
• supercedes: DRILL-2451 JDBC : Connection.commit throws an UnsupportedOperationException