-
Notifications
You must be signed in to change notification settings - Fork 26
feat: use a single multiplexed session for all operations #500
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
Merged
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
The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions.
bhatt4982
approved these changes
Aug 28, 2025
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM...
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements.
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <[email protected]> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <[email protected]>
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: parse SET/SHOW statements with simple parser Parse SET/SHOW statements using the simple parser. Any connection variable that is not covered by a regular expression client-side statement, will be picked up by this simple parser. In a following step, all regex-based client-side statements will be removed, and the parsing will happen using the simple parser. This further simplifies and unifies all client-side statement parsing and handling, and makes all connection variables transactional. * chore: fix formatting * chore: use a callback to supply tx opts (#496) * chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <[email protected]> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <[email protected]> --------- Co-authored-by: Sanjeev Bhatt <[email protected]> Co-authored-by: Mend Renovate <[email protected]>
olavloite
added a commit
that referenced
this pull request
Sep 3, 2025
* chore: add generic transactional connection state Adds data structures for generic transactional connection state. These structures will be used to keep all connection state in one place, making it easier to add new connection variables. This also adds support for transactional connection state; Changes that are made during a transaction are only persisted if the transaction is committed. It also allows for setting temporary (local) values during a transaction. This change is the first step in a multi-step process for moving all connection variables into a generic structure. Following changes will move the other connection variables into this structure, and will add support for executing `set local ...` statements. * chore: move connection variables to connection state Move individual connection variables to the generic connection state. * chore: fix formatting * chore: parse SET/SHOW statements with simple parser (#495) * chore: parse SET/SHOW statements with simple parser Parse SET/SHOW statements using the simple parser. Any connection variable that is not covered by a regular expression client-side statement, will be picked up by this simple parser. In a following step, all regex-based client-side statements will be removed, and the parsing will happen using the simple parser. This further simplifies and unifies all client-side statement parsing and handling, and makes all connection variables transactional. * chore: fix formatting * chore: use a callback to supply tx opts (#496) * chore: use a callback to supply tx opts Use a callback to supply transaction options, so changes to the connection variables at the start of a transaction (before it has actually been activated) are also included in the transaction. This is necessary to support SET LOCAL statements that have an impact on the actual transaction, such as the following example script: ``` BEGIN TRANSACTION; SET LOCAL ISOLATION_LEVEL='repeatable_read'; UPDATE my_table SET my_col=1 WHERE id=1; COMMIT; ``` This change depends on googleapis/google-cloud-go#12779 * fix: update all dependencies (#492) * fix: update all dependencies * chore: go mod tidy and update tests Update tests to match the behavior of using multiplexed sessions by default for all operations. --------- Co-authored-by: Knut Olav Løite <[email protected]> * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * chore: replace ExecOptions for connection variables (#497) * chore: replace ExecOptions for connection variables Replaces all ExecOptions with actual connection variables, and makes the ExecOptions field a real temporary field that is only used when the application passes in an ExecOptions instance as an argument for a statement. * feat: use a single multiplexed session for all operations (#500) The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool. One multiplexed session can execute any number of both read-only and read/write transactions concurrently. See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions. * chore: fix some flaky test cases (#499) * feat: create/drop database statements (#502) Support CREATE DATABASE and DROP DATABASE statements. --------- Co-authored-by: Mend Renovate <[email protected]> --------- Co-authored-by: Sanjeev Bhatt <[email protected]> Co-authored-by: Mend Renovate <[email protected]> --------- Co-authored-by: Sanjeev Bhatt <[email protected]> Co-authored-by: Mend Renovate <[email protected]>
Sign up for free
to join this conversation on GitHub.
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.
The Spanner database/sql driver now uses a single multiplexed session for all operations. Setting a value for MinSessions and MaxSessions is therefore no longer necessary for workloads that have a significantly higher or lower usage than can normally be served by the default session pool.
One multiplexed session can execute any number of both read-only and read/write transactions concurrently.
See https://cloud.google.com/spanner/docs/sessions#multiplexed_sessions for more information on multiplexed sessions.