chore(spanner): change begin transaction option to enum (step 8)#5327
Draft
olavloite wants to merge 23 commits intogoogleapis:mainfrom
Draft
chore(spanner): change begin transaction option to enum (step 8)#5327olavloite wants to merge 23 commits intogoogleapis:mainfrom
olavloite wants to merge 23 commits intogoogleapis:mainfrom
Conversation
Adds support for inlining the BeginTransaction with the first query in a read-only transaction. This saves one round-trip to Spanner for multi-use read-only transactions. This implementation is intentionally simple: 1. It does not support parallel queries at the start of the transaction. 2. It does not include error handling for the first query. 3. It only supports read-only transactions. This is step 1. Follow-up pull requests addresses the above points.
Adds error handling for inline-begin-transaction. If the first statement in a transaction fails, and that statement included a BeginTransaction option, then the transaction has not been started. In order to keep the semantics of the transaction consistent for an 'outside observer', we need to do the following: 1. Catch the error that was thrown by the initial statement. 2. Start the transaction using an explicit BeginTransaction RPC. 3. Retry the initial statement, but now using the transaction ID from step 2. 4. Return the error or result for the retried initial statement. The above makes sure that: 1. The transaction is actually started when the first statement is executed, also when the statement failed. 2. The statement becomes part of the transaction, and the result of the statement is consistent with the read-timestamp of the transaction. The second part is important in order to comply with Spanner's strong consistency guarantees; If for example a statement returns a 'Table not found' error, then that error is only valid for the read timestamp that was used for executing the statement. This is the reason that we retry the statement after the BeginTransaction RPC to be able to return a result that is guaranteed to be consistent with any other queries/reads that will be executed in the same transaction.
Adds an integration test for error handling for inline-begin-transaction. This test uses a gRPC proxy to intercept calls from the client to Spanner to be able to deterministically emulate specific concurrency issues. This test shows how a query that failed during the first attempt, and thereby also failed to start the transaction, could succeed during a retry after the transaction has been started with an explicit BeginTransaction RPC.
Adds support for running concurrent queries in combination with inline-begin-transaction. Only one of the queries will include the BeginTransaction option. The other queries will wait until the first query has returned a transaction ID.
If a query included a BeginTransaction option and the application never called ResultSet#next(), then the transaction ID would never be returned. This would block any other query from using the transaction. This change refactors ResultSet to use a background worker to read from the stream. This prevents that a deadlock can happen if the application does not call ResultSet#next(). It also allows the application to call ResultSet#metadata() without first calling ResultSet#next(). Finally, it also allows the ResultSet to decode data from the server asynchronously while the application processes rows that it has already read from the ResultSet.
Adds support for inline-begin for read/write transactions. This reduces the number of round-trips to Spanner by one for read/write transactions.
Enable the use of inline-begin-transaction for TransactionRunner.
Change the begin-transaction option from a boolean to an enum to allow more values in the future.
Adds error handling for inline-begin-transaction. If the first statement in a transaction fails, and that statement included a BeginTransaction option, then the transaction has not been started. In order to keep the semantics of the transaction consistent for an 'outside observer', we need to do the following: 1. Catch the error that was thrown by the initial statement. 2. Start the transaction using an explicit BeginTransaction RPC. 3. Retry the initial statement, but now using the transaction ID from step 2. 4. Return the error or result for the retried initial statement. The above makes sure that: 1. The transaction is actually started when the first statement is executed, also when the statement failed. 2. The statement becomes part of the transaction, and the result of the statement is consistent with the read-timestamp of the transaction. The second part is important in order to comply with Spanner's strong consistency guarantees; If for example a statement returns a 'Table not found' error, then that error is only valid for the read timestamp that was used for executing the statement. This is the reason that we retry the statement after the BeginTransaction RPC to be able to return a result that is guaranteed to be consistent with any other queries/reads that will be executed in the same transaction.
Adds error handling for inline-begin-transaction. If the first statement in a transaction fails, and that statement included a BeginTransaction option, then the transaction has not been started. In order to keep the semantics of the transaction consistent for an 'outside observer', we need to do the following: 1. Catch the error that was thrown by the initial statement. 2. Start the transaction using an explicit BeginTransaction RPC. 3. Retry the initial statement, but now using the transaction ID from step 2. 4. Return the error or result for the retried initial statement. The above makes sure that: 1. The transaction is actually started when the first statement is executed, also when the statement failed. 2. The statement becomes part of the transaction, and the result of the statement is consistent with the read-timestamp of the transaction. The second part is important in order to comply with Spanner's strong consistency guarantees; If for example a statement returns a 'Table not found' error, then that error is only valid for the read timestamp that was used for executing the statement. This is the reason that we retry the statement after the BeginTransaction RPC to be able to return a result that is guaranteed to be consistent with any other queries/reads that will be executed in the same transaction.
Adds an integration test for error handling for inline-begin-transaction. This test uses a gRPC proxy to intercept calls from the client to Spanner to be able to deterministically emulate specific concurrency issues. This test shows how a query that failed during the first attempt, and thereby also failed to start the transaction, could succeed during a retry after the transaction has been started with an explicit BeginTransaction RPC.
Adds an integration test for error handling for inline-begin-transaction. This test uses a gRPC proxy to intercept calls from the client to Spanner to be able to deterministically emulate specific concurrency issues. This test shows how a query that failed during the first attempt, and thereby also failed to start the transaction, could succeed during a retry after the transaction has been started with an explicit BeginTransaction RPC.
Adds support for running concurrent queries in combination with inline-begin-transaction. Only one of the queries will include the BeginTransaction option. The other queries will wait until the first query has returned a transaction ID.
Adds error handling for inline-begin-transaction. If the first statement in a transaction fails, and that statement included a BeginTransaction option, then the transaction has not been started. In order to keep the semantics of the transaction consistent for an 'outside observer', we need to do the following: 1. Catch the error that was thrown by the initial statement. 2. Start the transaction using an explicit BeginTransaction RPC. 3. Retry the initial statement, but now using the transaction ID from step 2. 4. Return the error or result for the retried initial statement. The above makes sure that: 1. The transaction is actually started when the first statement is executed, also when the statement failed. 2. The statement becomes part of the transaction, and the result of the statement is consistent with the read-timestamp of the transaction. The second part is important in order to comply with Spanner's strong consistency guarantees; If for example a statement returns a 'Table not found' error, then that error is only valid for the read timestamp that was used for executing the statement. This is the reason that we retry the statement after the BeginTransaction RPC to be able to return a result that is guaranteed to be consistent with any other queries/reads that will be executed in the same transaction.
Adds an integration test for error handling for inline-begin-transaction. This test uses a gRPC proxy to intercept calls from the client to Spanner to be able to deterministically emulate specific concurrency issues. This test shows how a query that failed during the first attempt, and thereby also failed to start the transaction, could succeed during a retry after the transaction has been started with an explicit BeginTransaction RPC.
Adds support for running concurrent queries in combination with inline-begin-transaction. Only one of the queries will include the BeginTransaction option. The other queries will wait until the first query has returned a transaction ID.
If a query included a BeginTransaction option and the application never called ResultSet#next(), then the transaction ID would never be returned. This would block any other query from using the transaction. This change refactors ResultSet to use a background worker to read from the stream. This prevents that a deadlock can happen if the application does not call ResultSet#next(). It also allows the application to call ResultSet#metadata() without first calling ResultSet#next(). Finally, it also allows the ResultSet to decode data from the server asynchronously while the application processes rows that it has already read from the ResultSet.
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #5327 +/- ##
==========================================
- Coverage 98.03% 97.76% -0.27%
==========================================
Files 214 220 +6
Lines 44324 48770 +4446
==========================================
+ Hits 43451 47680 +4229
- Misses 873 1090 +217 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Change the begin-transaction option from a boolean to an enum to allow more values in
the future.