[ https://issues.apache.org/jira/browse/CALCITE-5009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Istvan Toth updated CALCITE-5009: --------------------------------- Docs Text: Avatica will no longer tranparently create a new connection if the proxied connection object times out from the server side cache. The transparent reconnection feature can be enabled setting the "transparent_reconnection" JDBC property to true, but this is only recommended for connections where losing the connection state, including transactional state, is not a problem. However, it is recommended to tune the connection and server side cache parameters to avoid the cache expiry alltogether. was: Avatica will no longer tranparently create a new connection if the proxied connection object times out from the local cache, or becomes invalid for any other reason. The transparent reconnection feature can be enabled setting the "transparent_reconnection" JDBC property to true, but this is only recommended for connections where losing the connection state, including transactional state, is not a problem. > 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 > Time Spent: 0.5h > 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)