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

RUBY-1727 Unscope connection pools from clusters #1257

Merged
merged 2 commits into from Feb 21, 2019
Merged

Conversation

p-mongo
Copy link
Contributor

@p-mongo p-mongo commented Feb 19, 2019

No description provided.

@@ -274,7 +275,16 @@ def summary
#
# @since 2.0.0
def pool
@pool ||= cluster.pool(self)
@pool_lock.synchronize do
Copy link
Contributor

Choose a reason for hiding this comment

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

It doesn't look like the pool will ever be finalized unless the server itself is; why not just define a finalizer on server itself (or on all pools in the pool implementation) instead of defining one on the pool here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Instance variables of an object being finalized are not available. What exactly are you proposing to do?

Copy link
Contributor

Choose a reason for hiding this comment

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

I understand that. Let me rephrase my question; is there any reason why we only want to define finalizers to clean up connection pools that are instance variables of servers instead of just defining one in either the connection pool constructor or ConnectionPool#get?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Having the finalizer be set by the connection pool constructor is a better idea indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants