Optimize the isValid method to use a cached value #1443
Assignees
Labels
api: spanner
Issues related to the googleapis/java-spanner-jdbc API.
type: feature request
‘Nice-to-have’ improvement, new feature or different behavior or design.
Comments
olavloite
added
the
type: feature request
product-auto-label
bot
added
the
api: spanner
olavloite
added a commit
that referenced
this issue
Dec 13, 2023
Cloud Spanner JDBC connections do not maintain a physical connection to Cloud Spanner, but are merely a wrapper around the underlying Java client library. This again uses a pool of gRPC channels to communicate with Cloud Spanner. This means that a single JDBC connection will never lose its network connection with Cloud Spanner, and checking whether it is valid or not by executing a query every time is not useful. Instead, the check should: 1. Verify that a connection has successfully been established with Cloud Spanner. The result should be cached for all JDBC connections using the same Cloud Spanner client library instance. 2. Verify that the connection has not been closed. The above can be achieved by checking that the dialect of the database that the connection is connected to has been successfully fetched. This result is cached in the client library, and being able to get that means that there has been a valid connection. This means that the isValid method will still return true if the network connectivity has been lost completely between the client and Cloud Spanner. However, this check is mostly used by connection pools to determine whether a connection is safe to be handed out to an application, and when all network connectivity has been lost, this will apply to all JDBC connections and not just one, meaning that the check is void. The original isValid check can be enabled by setting the System property spanner.jdbc.use_legacy_is_valid_check to true or setting the Environment variable SPANNER_JDBC_USE_LEGACY_IS_VALID_CHECK to true. Fixes #1443
olavloite
added a commit
that referenced
this issue
Dec 19, 2023
Cloud Spanner JDBC connections do not maintain a physical connection to Cloud Spanner, but are merely a wrapper around the underlying Java client library. This again uses a pool of gRPC channels to communicate with Cloud Spanner. This means that a single JDBC connection will never lose its network connection with Cloud Spanner, and checking whether it is valid or not by executing a query every time is not useful. Instead, the check should: 1. Verify that a connection has successfully been established with Cloud Spanner. The result should be cached for all JDBC connections using the same Cloud Spanner client library instance. 2. Verify that the connection has not been closed. The above can be achieved by checking that the dialect of the database that the connection is connected to has been successfully fetched. This result is cached in the client library, and being able to get that means that there has been a valid connection. This means that the isValid method will still return true if the network connectivity has been lost completely between the client and Cloud Spanner. However, this check is mostly used by connection pools to determine whether a connection is safe to be handed out to an application, and when all network connectivity has been lost, this will apply to all JDBC connections and not just one, meaning that the check is void. The original isValid check can be enabled by setting the System property spanner.jdbc.use_legacy_is_valid_check to true or setting the Environment variable SPANNER_JDBC_USE_LEGACY_IS_VALID_CHECK to true. Fixes #1443
gcf-merge-on-green bot
pushed a commit
that referenced
this issue
Dec 22, 2023
🤖 I have created a release *beep* *boop* --- ## [2.15.0](https://togithub.com/googleapis/java-spanner-jdbc/compare/v2.14.6...v2.15.0) (2023-12-22) ### Features * Support PreparedStatement#getParameterMetaData() ([#1218](https://togithub.com/googleapis/java-spanner-jdbc/issues/1218)) ([721ff45](https://togithub.com/googleapis/java-spanner-jdbc/commit/721ff4552104efba47c19ef511282071c3b334c3)) ### Performance Improvements * Optimize isValid implementation ([#1444](https://togithub.com/googleapis/java-spanner-jdbc/issues/1444)) ([914e973](https://togithub.com/googleapis/java-spanner-jdbc/commit/914e973ad7fd638fabc3ec130b7618c51f01f401)), closes [#1443](https://togithub.com/googleapis/java-spanner-jdbc/issues/1443) ### Dependencies * Update dependency org.postgresql:postgresql to v42.7.1 ([#1441](https://togithub.com/googleapis/java-spanner-jdbc/issues/1441)) ([5997555](https://togithub.com/googleapis/java-spanner-jdbc/commit/59975553826360b86492e50b9d49c29aecc28bab)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
isValidmethod in a JDBC connection is used by connection pools to determine whether a connection is safe to hand out to an application. Executing a query each time for this is not very efficient for Cloud Spanner, as the Cloud Spanner JDBC connection is just a wrapper around the client library, and does not implement a physical connection with Cloud Spanner. This means that loss of network connectivity is 'all-or-nothing'; if the network connection to Cloud Spanner has been lost, then it will apply to all JDBC connections, and not only a specific one. There is therefore no point in repeatedly executing a query on Cloud Spanner to check whether a connection is valid or not.The text was updated successfully, but these errors were encountered: