[jira] [Assigned] (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 reassigned CALCITE-5009:
------------------------------------

    Assignee: Istvan Toth

> 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
>
> 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)