[jira] [Updated] (CALCITE-5009) Transparent JDBC connection re-creation may lead to data loss

["Istvan Toth (Jira)" <ji...@apache.org>]

     [ 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 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: 10m
>  Remaining Estimate: 0h
>
> 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)