[ https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Josh Elser resolved CALCITE-5009. --------------------------------- Fix Version/s: avatica-1.21.0 Resolution: Fixed > Transparent JDBC connection re-creation may lead to data loss > ------------------------------------------------------------- > > Key: CALCITE-5009 > URL: https://issues.apache.org/jira/browse/CALCITE-5009 > Project: Calcite > Issue Type: Bug > Components: avatica > Reporter: Istvan Toth > Assignee: Istvan Toth > Priority: Major > Fix For: avatica-1.21.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Currently, if the server-side JDBC connection goes away because it is expored > from the server-side connection cache we attempt to transparently create a > new "real" JDBC connection, and continue using that instead of the original > connection > [https://github.com/apache/calcite-avatica/blob/fbdcc62745a0e8920db759fb6bdce564d854e407/core/src/main/java/org/apache/calcite/avatica/AvaticaConnection.java#L796] > This is fine for most read-only connections, but it can break transaction > semantics, which is captured in the "real" connection object. > {noformat} > conn.setAutocommit(false) > stmt = conn.createStatement() > execute(insert A) > //Connection lost and object recreated which now proxies a new "real" > connection > execute(insert B) > conn.commit() > //We have lost "insert A"{noformat} > I'm not sure if we synchronize autocommit state of the new connection to the > lost one or not, but it's bad either way. > > We should either completely drop this feature, add some logic that avoids it > if there is an open transaction and/or only allow it for connections that > have the readOnly flag set. -- This message was sent by Atlassian Jira (v8.20.1#820001)