[ https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490487#comment-17490487 ]
Julian Hyde commented on CALCITE-5009: -------------------------------------- The code you referenced is inside a public method {{invokeWithRetries}}. It seems OK for a method with that name to retry. But what user operation is calling that method? > Make sure transaparent jdbc connection re-creation does not 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 > Priority: Major > > 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)