Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: transaction retry could fail if tx contained failed statements #688

Merged
merged 1 commit into from Dec 9, 2020

Conversation

olavloite
Copy link
Contributor

@olavloite olavloite commented Dec 8, 2020

Transaction retries in the Connection API / JDBC driver could fail if the following happened:

  1. The initial transaction contains a statement that returns an error that does not invalidate
    the transaction, such as for example a "Table not found" error, and that error is caught and
    handled by the application code.
  2. The retry attempt tries to execute the failed statement to verify that the statement still
    returns the same error. If however the transaction that is used by the retry has been aborted
    immediately before the execution of this statement, the statement will now return Aborted
    instead of the original error. That would be seen as a different error than the initial
    error and would fail the retry attempt.

When the above happens, the Aborted error in the retry should be propagated and the retry attempt should be restarted.

Fixes #685

Transaction retries in the Connection API / JDBC driver could fail if the following happened:
1. The initial transaction contains a statement that returns an error that does not invalidate
   the transaction, such as for example a "Table not found" error, and that error is caught and
   handled by the application code.
2. The retry attempt tries to execute the failed statement to verify that the statement still
   returns the same error. If however the transaction that is used by the retry has been aborted
   immediately before the execution of this statement, the statement will now return Aborted
   instead of the original error. That would be seen as a different error than the initial
   error and would fail the retry attempt.

When the above happens, the Aborted error in the retry should be propagated and the retry
attempt should be restarted.

Fixes #685
@olavloite olavloite requested a review from thiagotnunes Dec 8, 2020
@olavloite olavloite requested a review from as a code owner Dec 8, 2020
@google-cla google-cla bot added the cla: yes label Dec 8, 2020
@product-auto-label product-auto-label bot added the api: spanner label Dec 8, 2020
@olavloite olavloite added the kokoro:force-run label Dec 9, 2020
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run label Dec 9, 2020
@olavloite olavloite added the kokoro:force-run label Dec 9, 2020
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run label Dec 9, 2020
@codecov
Copy link

@codecov codecov bot commented Dec 9, 2020

Codecov Report

Merging #688 (8e93b72) into master (d093089) will increase coverage by 0.22%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #688      +/-   ##
============================================
+ Coverage     84.12%   84.35%   +0.22%     
- Complexity     2509     2516       +7     
============================================
  Files           142      142              
  Lines         13911    13917       +6     
  Branches       1323     1323              
============================================
+ Hits          11703    11740      +37     
+ Misses         1662     1623      -39     
- Partials        546      554       +8     
Impacted Files Coverage Δ Complexity Δ
...le/cloud/spanner/connection/FailedBatchUpdate.java 55.17% <100.00%> (+25.54%) 2.00 <0.00> (+1.00)
...m/google/cloud/spanner/connection/FailedQuery.java 75.86% <100.00%> (+38.82%) 2.00 <0.00> (+1.00)
.../google/cloud/spanner/connection/FailedUpdate.java 75.00% <100.00%> (+38.63%) 2.00 <0.00> (+1.00)
...m/google/cloud/spanner/connection/SpannerPool.java 84.44% <0.00%> (-1.67%) 31.00% <0.00%> (ø%)
...cloud/spanner/connection/ReadWriteTransaction.java 82.02% <0.00%> (+1.12%) 55.00% <0.00%> (ø%)
...ud/spanner/SessionPoolAsyncTransactionManager.java 86.99% <0.00%> (+1.62%) 13.00% <0.00%> (+2.00%)
.../google/cloud/spanner/SpannerExceptionFactory.java 84.53% <0.00%> (+2.06%) 47.00% <0.00%> (+1.00%)
...ogle/cloud/spanner/connection/RetriableUpdate.java 90.00% <0.00%> (+10.00%) 3.00% <0.00%> (ø%)
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d093089...8e93b72. Read the comment docs.

@thiagotnunes thiagotnunes merged commit f78c64e into master Dec 9, 2020
21 checks passed
@thiagotnunes thiagotnunes deleted the issue-685 branch Dec 9, 2020
thiagotnunes pushed a commit that referenced this issue May 6, 2021
…688)

Transaction retries in the Connection API / JDBC driver could fail if the following happened:
1. The initial transaction contains a statement that returns an error that does not invalidate
   the transaction, such as for example a "Table not found" error, and that error is caught and
   handled by the application code.
2. The retry attempt tries to execute the failed statement to verify that the statement still
   returns the same error. If however the transaction that is used by the retry has been aborted
   immediately before the execution of this statement, the statement will now return Aborted
   instead of the original error. That would be seen as a different error than the initial
   error and would fail the retry attempt.

When the above happens, the Aborted error in the retry should be propagated and the retry
attempt should be restarted.

Fixes #685
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner cla: yes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants