Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-5009

Transparent JDBC connection re-creation may lead to data loss

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • avatica-1.21.0
    • avatica
    • None
    • Hide
      Avatica will no longer tranparently create a new connection if the proxied connection object expires 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.
      Show
      Avatica will no longer tranparently create a new connection if the proxied connection object expires 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.

    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

      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.

      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

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            stoty Istvan Toth
            stoty Istvan Toth
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 50m
                50m

                Slack

                  Issue deployment