Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
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
This is fine for most read-only connections, but it can break transaction semantics, which is captured in the "real" connection object.
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"
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.
Attachments
Issue Links
- is caused by
-
CALCITE-903 Enable client to recover from missing server-side state
- Closed
- relates to
-
CALCITE-5438 Document transparent_reconnection property
- Resolved
- links to