[v3-2-test] Ensure that DB migrations run in a single connection. (#65231)#65368
Merged
[v3-2-test] Ensure that DB migrations run in a single connection. (#65231)#65368
Conversation
…nection. (#65231) This was discovered by running with a custom External DB manager that had some gnarly queries that ended up being locked behind this transaction. `_single_connection_pool` replaces `settings.engine` with a SingletonThreadPool engine. But `work_session` was created before that — it still holds an internal reference to the old engine object. _single_connection_pool has no way to rebind work_session. So when _get_current_revision(session=work_session) runs on line 1203 — inside the _single_connection_pool() block — it calls session.connection() which goes through the old engine, not the SingletonThreadPool. The old engine's pool was disposed and recreated empty by engine.dispose(), so it creates a brand new connection. That connection is completely outside _single_connection_pool's control. _single_connection_pool guarantees one connection on the new engine. It can't prevent work_session from creating connections on the old one. The name is a bit of a lie — it's really "single connection pool for new code that uses settings.engine", not "single connection total." (cherry picked from commit e3fea3a) (cherry picked from commit f8e0876) Co-authored-by: Ash Berlin-Taylor <ash@apache.org>
ashb
changed the title
vatsrahul1001
pushed a commit
that referenced
this pull request
Apr 17, 2026
…nection. (#65231) (#65368) This was discovered by running with a custom External DB manager that had some gnarly queries that ended up being locked behind this transaction. `_single_connection_pool` replaces `settings.engine` with a SingletonThreadPool engine. But `work_session` was created before that — it still holds an internal reference to the old engine object. _single_connection_pool has no way to rebind work_session. So when _get_current_revision(session=work_session) runs on line 1203 — inside the _single_connection_pool() block — it calls session.connection() which goes through the old engine, not the SingletonThreadPool. The old engine's pool was disposed and recreated empty by engine.dispose(), so it creates a brand new connection. That connection is completely outside _single_connection_pool's control. _single_connection_pool guarantees one connection on the new engine. It can't prevent work_session from creating connections on the old one. The name is a bit of a lie — it's really "single connection pool for new code that uses settings.engine", not "single connection total." (cherry picked from commit e3fea3a) (cherry picked from commit f8e0876) Co-authored-by: Ash Berlin-Taylor <ash@apache.org>
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.
This was discovered by running with a custom External DB manager that had some
gnarly queries that ended up being locked behind this transaction.
_single_connection_poolreplacessettings.enginewith aSingletonThreadPool engine. But
work_sessionwas created before that — itstill holds an internal reference to the old engine object.
_single_connection_pool has no way to rebind work_session.
So when _get_current_revision(session=work_session) runs on line 1203 — inside
the _single_connection_pool() block — it calls session.connection() which goes
through the old engine, not the SingletonThreadPool. The old engine's pool was
disposed and recreated empty by engine.dispose(), so it creates a brand new
connection. That connection is completely outside _single_connection_pool's
control.
_single_connection_pool guarantees one connection on the new engine. It can't
prevent work_session from creating connections on the old one. The name is a
bit of a lie — it's really "single connection pool for new code that uses
settings.engine", not "single connection total."
(cherry picked from commit e3fea3a)
Co-authored-by: Ash Berlin-Taylor ash@apache.org