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

Consider forcing upper limit for connection pool by blocking #747

Closed
lauxjpn opened this issue Dec 7, 2019 · 4 comments
Closed

Consider forcing upper limit for connection pool by blocking #747

lauxjpn opened this issue Dec 7, 2019 · 4 comments
Labels

Comments

@lauxjpn
Copy link
Contributor

lauxjpn commented Dec 7, 2019

There is an issue on StackOverflow regarding a (seemingly) unbounded number of connections that can be opened.

This is consistent with the description from the docs:

Pooling:
Enables connection pooling. When pooling is enabled, MySqlConnection.Open retrieves an open connection from the pool if one is available (opening a new connection if not), and Close/Dispose returns the open connection to the pool.

I first considered this expected, as it is the responsibility of the user to take care of the number of connections he wants.

But there is a great talk from @roji about lock-free database pool development that makes a strong counter case for forcing an upper limit and blocking/waiting when exceeded.

(BTW, the talk is directly about #462 and with a lot of useful low level information.)

Maybe this behavior could be made the default, so users don't create too many connections by accident (as in the StackOverflow case), and the previous one opt-in?

@bgrainger
Copy link
Member

This is a documentation error, if you are interpreting the docs to mean that you can create an unlimited number of connections.

When pooling is true, each connection pool (there is one per unique connection string) only allows MaximumPoolSize connections to be open simultaneously. Each additional call to MySqlConnection.Open will block until a connection is returned to the pool.

When pooling is false, there is no limit to the number of connections that can be opened simultaneously; it's up to the user to manage the concurrency.

@bgrainger
Copy link
Member

I can look into this if you have a repro (e.g., with Pooling=true;MaxPoolSize=10 in the connection string) that opens more than 10 connections.

There's a test that verifies that the connection pool blocks OpenAsync when it's exhausted:

public async Task ExhaustConnectionPool()

@lauxjpn
Copy link
Contributor Author

lauxjpn commented Dec 7, 2019

Okay thanks! I will see if I can reproduce the described behavior in the SO post.

bgrainger added a commit that referenced this issue Dec 7, 2019
@bgrainger
Copy link
Member

I pushed a docs change: ff3da11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants