-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Fix checking cancelled connections back into the connection pool #1095
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 checking cancelled connections back into the connection pool #1095
Conversation
649efc7
to
dee6989
Compare
Github didn't get the memo but if you click through to the travis build it's green. |
driver_test.go
Outdated
if err != nil { | ||
dbt.Fatal(err) | ||
} | ||
|
||
// Delay execution for just a bit until db.ExecContext has begun. | ||
defer time.AfterFunc(100*time.Millisecond, cancel).Stop() | ||
go time.AfterFunc(100*time.Millisecond, cancel) |
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.
Why this change?
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.
I actually didn't understand how this was working at all - what it looked like it should be doing was canceling the context whilst the SQL was executing SLEEP(1)
, so I turned it into this.
I just read the docs for time.AfterFunc
more carefully and I think we can just invoke it on the main goroutine instead of calling go
?
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.
Eurgh - ok the problem is I just don't know how defer works. This is going to cause time.AfterFunc()
to run now, and then Stop()
to run when the method returns. I'll change it back.
dee6989
to
1b73282
Compare
If * BeginTx is called with a non-default isolation level, * The context is canceled before SET TRANSACTION ISOLATION LEVEL completes, then the connection: * has the cancelled property set to "context cancelled", * has the closed property set to true, and, * BeginTx returns "context canceled" Because of this, the connection gets put back into the connection pool. When it is checked out again, if BeginTx is called on it again _without_ an isolation level, * then we fall into the mc.closed.IsSet() check in begin(), * so we return ErrBadConn, * so the driver kicks the broken connection out of the pool * (and transparently retries to get a new connection that isn't broken too). However, if BeginTx is called on the connection _with_ an isolation level, then we return a context canceled error from the SET TRANSACTION ISOLATION LEVEL call. That means the broken connection will stick around in the pool forever (or until it's checked out for some other operation that correctly returns ErrBadConn). The fix is to check for the connection being closed before executing SET TRANSACTION ISOLATION LEVEL.
1b73282
to
978b6bd
Compare
Thank you for a quick review & merge! |
…sql-driver#1095) If * BeginTx is called with a non-default isolation level, * The context is canceled before SET TRANSACTION ISOLATION LEVEL completes, then the connection: * has the cancelled property set to "context cancelled", * has the closed property set to true, and, * BeginTx returns "context canceled" Because of this, the connection gets put back into the connection pool. When it is checked out again, if BeginTx is called on it again _without_ an isolation level, * then we fall into the mc.closed.IsSet() check in begin(), * so we return ErrBadConn, * so the driver kicks the broken connection out of the pool * (and transparently retries to get a new connection that isn't broken too). However, if BeginTx is called on the connection _with_ an isolation level, then we return a context canceled error from the SET TRANSACTION ISOLATION LEVEL call. That means the broken connection will stick around in the pool forever (or until it's checked out for some other operation that correctly returns ErrBadConn). The fix is to check for the connection being closed before executing SET TRANSACTION ISOLATION LEVEL.
…sql-driver#1095) If * BeginTx is called with a non-default isolation level, * The context is canceled before SET TRANSACTION ISOLATION LEVEL completes, then the connection: * has the cancelled property set to "context cancelled", * has the closed property set to true, and, * BeginTx returns "context canceled" Because of this, the connection gets put back into the connection pool. When it is checked out again, if BeginTx is called on it again _without_ an isolation level, * then we fall into the mc.closed.IsSet() check in begin(), * so we return ErrBadConn, * so the driver kicks the broken connection out of the pool * (and transparently retries to get a new connection that isn't broken too). However, if BeginTx is called on the connection _with_ an isolation level, then we return a context canceled error from the SET TRANSACTION ISOLATION LEVEL call. That means the broken connection will stick around in the pool forever (or until it's checked out for some other operation that correctly returns ErrBadConn). The fix is to check for the connection being closed before executing SET TRANSACTION ISOLATION LEVEL.
…ool (go-sql-driver#1095)" This reverts commit 6313f20.
Description
If
then the connection:
and,
Because of this, the connection gets put back into the connection pool. When it is checked out again, if BeginTx is called on it again without an isolation level,
However, if BeginTx is called on the connection with an isolation
level, then we return a context canceled error from the SET TRANSACTION
ISOLATION LEVEL call.
That means the broken connection will stick around in the pool forever
(or until it's checked out for some other operation that correctly
returns ErrBadConn).
The fix is to check for the connection being closed before executing SET
TRANSACTION ISOLATION LEVEL.
Checklist