Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Comment on lines +345 to +346
| .setInitialRpcTimeout(options.getPartitionedDmlTimeout()) | ||
| .setMaxRpcTimeout(options.getPartitionedDmlTimeout()) |
There was a problem hiding this comment.
Are PDML requests not meant to be retried? I'm just curious why the initial and max timeouts are the same.
There was a problem hiding this comment.
Good question.
I would say it's a a matter of probabilities and a little bit opinion:
- PDML is designed to accept long running update statements. That means that we should not automatically retry the statement if it takes longer than X time, as it would be impossible to find a good global value for X, as we don't know whether the statement is taking a long time because of a network problem or because the statement itself is taking a long time. Re-sending a long-running statement that is still running on the server would only hurt performance. My opinion is that for a PDML statement the chance that the statement is actually taking a long time is more probable than a network problem.
- The PDML documentation also clearly states that the update statement should be idempotent. This means that we should automatically retry it if the server is unavailable.
I think we should consider adding an additional method to the public API which would allow the users to specify a lower timeout for a specific statement, in addition to the current global setting. That would give the user more control over the timeout setting for statements that are known to take less time than the global setting.
There was a problem hiding this comment.
I've added an extra test case to ensure that PDML is retried on UNAVAILABLE.
Setting a timeout value for Partitioned DML would not be respected if the timeout value was higher than the timeout value set for the ExecuteSql RPC on the SpannerStub. Lower timeout values would be respected. Fixes #199
gcf-merge-on-green bot pushed a commit that referenced this pull request May 19, 2020
🤖 I have created a release \*beep\* \*boop\* --- ## [1.55.0](https://www..com/googleapis/java-spanner/compare/v1.54.0...v1.55.0) (2020-05-19) ### Features * mark when a Spanner client is closed ([#198](https://www..com/googleapis/java-spanner/issues/198)) ([50cb174](https://www..com/googleapis/java-spanner/commit/50cb1744e7ede611758d3ff63b3df77a1d3682eb)) ### Bug Fixes * make it possible to override backups methods ([#195](https://www..com/googleapis/java-spanner/issues/195)) ([2d19c25](https://www..com/googleapis/java-spanner/commit/2d19c25ba32847d116194565e67e1b1276fcb9f8)) * Partitioned DML timeout was not always respected ([#203](https://www..com/googleapis/java-spanner/issues/203)) ([13cb37e](https://www..com/googleapis/java-spanner/commit/13cb37e55ddfd1ff4ec22b1dcdc20c4832eee444)), closes [#199](https://www..com/googleapis/java-spanner/issues/199) * partitionedDml stub was not closed ([#213](https://www..com/googleapis/java-spanner/issues/213)) ([a2d9a33](https://www..com/googleapis/java-spanner/commit/a2d9a33fa31f7467fc2bfbef5a29c4b3f5aea7c8)) * reuse clientId for invalidated databases ([#206](https://www..com/googleapis/java-spanner/issues/206)) ([7b4490d](https://www..com/googleapis/java-spanner/commit/7b4490dfb61fbc81b5bd6be6c9a663b36b5ce402)) * use nanos to prevent truncation errors ([#204](https://www..com/googleapis/java-spanner/issues/204)) ([a608460](https://www..com/googleapis/java-spanner/commit/a60846043dc0ca47e1970d8ab99380b6d725c7a9)), closes [#200](https://www..com/googleapis/java-spanner/issues/200) ### Dependencies * update dependency com.google.cloud:google-cloud-shared-dependencies to v0.3.1 ([#190](https://www..com/googleapis/java-spanner/issues/190)) ([ad41a0d](https://www..com/googleapis/java-spanner/commit/ad41a0d4b0cc6a2c0ae0611c767652f64cfb2fb7)) --- This PR was generated with [Release Please](https://.com/googleapis/release-please).
rajatbhatta pushed a commit to rajatbhatta/java-spanner that referenced this pull request Nov 17, 2022
* chore: updated versions.txt [ci skip] * chore: updated samples/pom.xml [ci skip] * chore: updated samples/install-without-bom/pom.xml [ci skip] * chore: updated samples/snippets/pom.xml [ci skip] * chore: updated pom.xml [ci skip] * chore: updated samples/snapshot/pom.xml Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply..com>
Sign up for free to join this conversation on . Already have an account? Sign in to comment
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
Setting a timeout value for Partitioned DML would not be respected if the timeout value was higher than the timeout value set for the ExecuteSql RPC on the SpannerStub. Lower timeout values would be respected.
Fixes #199