Skip to content
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

per-thread connections #1336

Merged
merged 2 commits into from
Mar 8, 2019

Conversation

beckjake
Copy link
Contributor

@beckjake beckjake commented Mar 5, 2019

Fixes #1312

Bind connections to threads, rather than to names. Names are attached to connections, but only show up in logging. Threads get a connection assigned to them and re-use/rename it as necessary. I ended up enforcing that with a locked dictionary instead of thread-local storage because the main thread needs access to the connection object for query cancellation.

This removes model_name/connection_name from adapter methods, and the old available_raw decorator is now just named available, and the DatabaseWrapper no longer injects model_name.

One user-facing change: Parsing now always opens a connection instead of waiting to need it, which simplifies the connection logic a lot but does open a socket that isn't always necessary. I think it's ok, but if we have to I can do clever things to try to defer the actual opening until it's needed.

I spent a lot of time trying to break this and failed, but I still kind of expect to find significant edge-case bugs.

@beckjake beckjake force-pushed the feature/one-connection-per-thread branch 5 times, most recently from f165bf8 to 13c1a71 Compare March 6, 2019 19:00
@beckjake beckjake marked this pull request as ready for review March 6, 2019 19:00
parsing now always opens a connection, instead of waiting to need it
remove model_name/available_raw/etc
@beckjake beckjake force-pushed the feature/one-connection-per-thread branch from 13c1a71 to e2af871 Compare March 6, 2019 19:11
Copy link
Contributor

@drewbanin drewbanin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots to pore over here but some initial testing looks really good! Some questions in the comments, but nothing to major yet! I ran this on BQ, Snowflake, and Redshift across run/test/archive with realistic prod workloads and it worked great


adapter.release_connection(model_name)
adapter.release_connection()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we want to close the connection here? or is that handled by the context manager?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't close the actual connection until the connection enters an error state or at the end of execution entirely (the finally block of execute_with_hooks).

self.safe_run_hooks(adapter, RunHookType.Start, {})
with adapter.connection_named('master'):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do this twice?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A mistake!

Copy link
Contributor

@drewbanin drewbanin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel pretty good about merging this and making tweaks as needed in development. We're early in the release cycle for Wilt Chamberlain, so I'm confident in our ability to squash any hard-to-find bugs as we build on top of this!

@beckjake beckjake merged commit 2090887 into dev/wilt-chamberlain Mar 8, 2019
@beckjake beckjake deleted the feature/one-connection-per-thread branch March 8, 2019 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants