Bug #450: Re-enable using connection pooling by default for SQL server#451
Merged
Bug #450: Re-enable using connection pooling by default for SQL server#451
Conversation
Collaborator
Author
|
FYI, @wokket - please scream out if 1.6.2 introduces any issues for your use case (when it comes out) - or, even better, if you have the chance to run against a locally built version from source (latest main) and confirm that it does indeed work for you if you change the transaction handling of the RunAfterCreateDatabase to Autonomous. |
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.
When solving #232 , the solution was to disable connection pooling by default it not explicitly set to "true" in the SQL server connection string. This did solve the problem, but setting "Pooling=true" in the connection string is rather unusual with SQL Server, as this is the default.
Disabling pooling severely affects performance negatively, especially on authentication types that takes a while to establish, e.g. Azure AD authentication. When the pooling is disabled, the connection is actually closed every time we close it, instead of being returned to the connection pool, ready to be re-used without authenticating again (and taking the performance hit).
This PR removes explicitly turning off connection pooling if not explicitly set to true in the connection string. Running the runAfterCreateDatabase scripts in an autonomous transaction should be a better workaround for the issue in question, and avoids the performance hit for the common usage scenarios