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

added lazy loading option for connection pool #37

Closed
wants to merge 4 commits into from

Conversation

@coelhone
Copy link

@coelhone coelhone commented Sep 2, 2013

Lazy loading option added.
Used passing :loading => :lazy to ConnectionPool's initializer (defaults to :eager).
When a connection is requested by the client, the pool's:

  1. creates one and returns it if it was empty (still have open slots - all connections were being used)
  2. returns one if it's available
  3. returns an ConnectionPool::ConnectionPoolFullException if all connection slots are being used
private

def create_connection
@existing_conns_count += 1
Copy link
Owner

@mperham mperham Sep 2, 2013

I'm unclear why the Pool needs to know the existing count. The connection creation and counting should all be tracked inside TimedStack IMO.

@chandresh
Copy link

@chandresh chandresh commented Sep 13, 2013

+1

@djanowski
Copy link
Collaborator

@djanowski djanowski commented Sep 13, 2013

May I ask the use case for lazy loading?

@coelhone
Copy link
Author

@coelhone coelhone commented Sep 13, 2013

Hi, for example, you can have a global variable on your app creating a
client (in my case a cassandra one), that you want to use it with the app
and some tasks. Running other tasks that share the same environment, but
would not use the client, would create connections that wouldn't be used.
Connections will only be created on demand and if needed.

@djanowski
Copy link
Collaborator

@djanowski djanowski commented Sep 13, 2013

Then why not simply define a global method (rather than a variable) which lazily creates the variable with the pool?

@coelhone
Copy link
Author

@coelhone coelhone commented Sep 13, 2013

That could be a solution, however, there would still be connections opened
to the DB that (pottencially) would never be used

2013/9/13 Damian Janowski notifications@github.com

Then why not simply define a global method (rather than a variable) which
lazily creates the variable with the pool?


Reply to this email directly or view it on GitHubhttps://github.com//pull/37#issuecomment-24397757
.

Bruno Coelho

@antonioleonardo
Copy link

@antonioleonardo antonioleonardo commented Sep 18, 2013

+1

@djanowski
Copy link
Collaborator

@djanowski djanowski commented Sep 18, 2013

@coelhone If you never call the global method, then the pool won't be created. If this is such a big issue for you, I think you should create pools of objects which close connections after a certain amount of time.

I'm -1 on bringing this complexity to the gem for a quite contrived use case.

@coelhone
Copy link
Author

@coelhone coelhone commented Sep 18, 2013

I only gave you one example, the lazy load feature (IMHO) is best suited
for cases when you want to have the minimum required connections (at a
certain time, at a certain environment, at a certain task, etc...). This is
not a single use case and, has is referenced by the project, it is supposed
to be generic.
If i close connections after a certain amount of time, the problem of
having connections created without any use being given to them, still
persists.

Nevertheless, thanks for the reply

@coelhone coelhone closed this Sep 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants