Istvan Toth created CALCITE-5009:
------------------------------------
Summary: Remove transaparent jdbc connection re-creation code
Key: CALCITE-5009
URL: https://issues.apache.org/jira/browse/CALCITE-5009
Project: Calcite
Issue Type: Bug
Components: avatica
Reporter: Istvan Toth
Currently, if the server-side JDBC connection goes away for any reason
* Avatica connection cache expiry
* LB/HA Failover
* Some problem with the "real" connection
we attempt to 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)
