establish connection creates new connection pool on each request

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

establish connection creates new connection pool on each request

vaibhav paliwal
Hi,

In our rails application we need to establish connection to database based on the client id in the URL. Currently we are using establish_connection but it looks like it creates new connection pool each time and executes some queries to get schema information about DB. Is there a way to cache connection pool ? I am also curious why did Active Record decided not to cache the connection pools based on configuration ? I am not sure if its a great idea to subclass ConnectionHandler and roll my own connection pool caching something like thisĀ any opinions ?

Thanks

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: establish connection creates new connection pool on each request

Walter Lee Davis
Are you seeing this in development or production? I would expect this behavior in development, but never in production. In my experience, connection pools are established and maintained for the run-time of the application. Naturally, if you are deployed in an auto-scaling environment, each instance of your app will get its own pool(s), but that's to be expected.

Walter

> On Dec 21, 2017, at 9:11 AM, vaibhav paliwal <[hidden email]> wrote:
>
> Hi,
>
> In our rails application we need to establish connection to database based on the client id in the URL. Currently we are using establish_connection but it looks like it creates new connection pool each time and executes some queries to get schema information about DB. Is there a way to cache connection pool ? I am also curious why did Active Record decided not to cache the connection pools based on configuration ? I am not sure if its a great idea to subclass ConnectionHandler and roll my own connection pool caching something like this any opinions ?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> To post to this group, send email to [hidden email].
> To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/3A748167-EA1F-473B-A0B6-85BCF8748446%40wdstudio.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: establish connection creates new connection pool on each request

vaibhav paliwal
Thanks for your reply. I am seeing this in production. I thought connection pool will be maintained for the run time of application too but looking at the establish_connection source code it looks like it clears the existing pools and creates a new connection pool. I thought it would be checking if there is already a connection pool existing for the spec and if not then create the connection pool.
This makes me wonder if its a good idea to cache connection pool in an ivar in my application when Active Record decided not to do it.


On Friday, December 22, 2017 at 9:03:13 AM UTC-6, Walter Lee Davis wrote:
Are you seeing this in development or production? I would expect this behavior in development, but never in production. In my experience, connection pools are established and maintained for the run-time of the application. Naturally, if you are deployed in an auto-scaling environment, each instance of your app will get its own pool(s), but that's to be expected.

Walter

> On Dec 21, 2017, at 9:11 AM, vaibhav paliwal <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="ztY2Ly1kAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">vaibhav....@...> wrote:
>
> Hi,
>
> In our rails application we need to establish connection to database based on the client id in the URL. Currently we are using establish_connection but it looks like it creates new connection pool each time and executes some queries to get schema information about DB. Is there a way to cache connection pool ? I am also curious why did Active Record decided not to cache the connection pools based on configuration ? I am not sure if its a great idea to subclass ConnectionHandler and roll my own connection pool caching something like this any opinions ?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="ztY2Ly1kAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="ztY2Ly1kAgAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">rubyonra...@googlegroups.com.
> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com&#39;;return true;">https://groups.google.com/d/msgid/rubyonrails-talk/52905ce6-8bc9-422f-becd-ab8609cfc7f2%40googlegroups.com.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/21f287aa-454a-4e13-8873-cff7d3b8a41c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.