-
Notifications
You must be signed in to change notification settings - Fork 264
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
Mssql connection pooling issue. Multiple server round trips per query. #1061
Comments
@igalklebanov @koskimas Any input on ways this could be addressed beyond what I suggest? I hope to implement a fix when time allows some time this week or the next. |
Unfortunately I know nothing about the dialect or mssql in general. @igalklebanov is needed for this one. |
Hey 👋 Are there any risks? |
@igalklebanov The I looked into how other db drivers handle acquiring and releasing connections from a pool. From what I can tell So from what I can tell, making this change is not enabling something out of the ordinary. |
OK. Let's validate like in Let's split the reset change into 2 efforts:
|
Sounds reasonable to me. Here is a PR to add the new configs. |
The problem
I was looking through OpenTelemtry traces of an application that uses Kysely with mssql and noticed that for every user created Kysley query, 3 SQL queries get sent to the server in succession.
The first is sent when a connection is acquired from the tarn connection pool. Every time this happens, tarn calls the provided
validate
method, which in this casesends a query
.The seconds is the user defined query.
The third happens with the connection is released back to the connection pool. The
releaseConnection
method calls thePRIVATE_RELEASE_METHOD
, which calls thereset
method defined in tedious, which in turn executes this query.The 2 bookending queries create additional application latency by adding 2 round trips to the database server. I am assuming that this behavior is not expected and that there should only be one round trip to the database per user defined query. If I am wrong, please let me know.
How to reproduce
I created a demo repo with steps to reproduce this with trace logging and example traces.
Possible solution
I think the easiest and safest way to address this is to allow the user to configure the pool validation function and if the tedious
reset
method should be called when a connection is released. The default behavior can be the same as it is now, but this gives the opportunity to opt out.The text was updated successfully, but these errors were encountered: