When should I use the connection pool?

352 views
Skip to first unread message

cyd...@gmail.com

unread,
Jun 17, 2016, 10:32:25 AM6/17/16
to golang-nuts
Hi to all,
I'm new here and using golang too. I've read some articles and post on Connection Pooling" but I'm still confused. What I'm looking for is a rule of thumb that make me easy to decide when use connection pool. My scenario isn't so complicated:

 - a web application that makes CRUD operations on a Postgres database.
 - Minimun 10 clients connected up to 30.

Moreover, I'm going to use pgx driver. I'd be grateful if you could help me to get the difference from use or not the connection pool, which is the best practice?

Thanks in advance,

Danilo

Ain

unread,
Jun 17, 2016, 11:01:04 AM6/17/16
to golang-nuts
The documentation of the Open method in database/sql package (https://golang.org/pkg/database/sql/#Open) reads:

<<The returned DB is safe for concurrent use by multiple goroutines and maintains its own pool of idle connections. Thus, the Open function should be called just once. It is rarely necessary to close a DB. >>

HTH
ain

Danilo Cicerone

unread,
Jun 17, 2016, 5:26:08 PM6/17/16
to golang-nuts
Thanks ain, that's another brick in the wall.

Danilo Cicerone

unread,
Jun 18, 2016, 2:01:54 AM6/18/16
to golang-nuts
Great, I found this page "https://www.vividcortex.com/blog/2015/01/19/gos-connection-pool-retries-and-timeouts/ and it's really useful!!!
Hope to help someone else.

Simon Ritchie

unread,
Jun 18, 2016, 3:31:26 AM6/18/16
to golang-nuts
Every database offers a limited number of connections because each of them eats resources.  If you are using your database in a commercial environment, you configure your database with a maximum number of connections.  If you don't do that, the DB will configure some default maximum, it won't offer an unlimited number.  So each client application should be written so that it handles a refusal to provide a connection gracefully, and it should close every connection as soon as it has finished with it, otherwise you can run out of connections without good reason.  Good practice is to write your application to always close connections as soon as it's finished with them.  In the case of Go, the defer mechanism can be used to make this more reliable.  However, the app can still hold onto connections, maybe due to programming mistakes.  A connection pool enforces a maximum number of connections that a single app can hold, so it stops your app from asking for more than its share.  It also watches for idle connections and closes them for you.  It's good practice to use a connection pool to iron out the problems that your app fails to handle itself.

Hope this helps.

Simon

Danilo Cicerone

unread,
Jun 18, 2016, 9:47:18 AM6/18/16
to golang-nuts
Thanks Simon, that helps me a lot.

Chris Hines

unread,
Jun 18, 2016, 8:14:00 PM6/18/16
to golang-nuts
Note that the implementation of database/sql has been updated since that article was written so that it behaves much better under the conditions described.
Reply all
Reply to author
Forward
0 new messages