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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Do you need to close the db connection every request? #1427

Closed
samgavinio opened this issue Apr 9, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@samgavinio
Copy link

commented Apr 9, 2017

Hi 馃憢, please label this github issue as a question.

Just recently got into labstack/echo with gorm as the ORM and I've noticed that the echo cookbooks out there generally show that you would clone a new connection and close it every request.

Looking at the gorm docs, there doesn't seem be anything specific about doing this and most of the stuff I've seen generally just open one persistent connection and pass it around.

Is there anything note worthy in doing either with gorm?

@samgavinio

This comment has been minimized.

Copy link
Author

commented Apr 9, 2017

Found a sufficiently good answer here: #1053

@samgavinio samgavinio closed this Apr 9, 2017

@ghost

This comment has been minimized.

Copy link

commented Apr 11, 2017

@samgavinio Can you quickly summarize? Is it okay to Open a connection and use it everywhere else in the app and defer db.Close() it? Thanks!

@sgon00

This comment has been minimized.

Copy link

commented May 18, 2017

I had the same question and after reading 5 related issues, I am still confused right now and don't know which way is the best practice. The official gorm doc just shows defer db.Close() way which is opening and closing a connection in every request. I think opening and closing DB connection takes a lot of time and resources, but it seems gorm recommends this way.

@samgavinio I am wondering what your final decision is? thanks.

@stretchkennedy

This comment has been minimized.

Copy link

commented Sep 27, 2017

For anyone who comes across this issue later on, the correct way to deal with database connections in a long-running application is something like

func main() {
  db, err := gorm.Open("sqlite3", "example.db")
  if err != nil {
    log.Fatal(err)
  }
  defer db.Close()

  // if your program has a main loop, start it here
  // i.e. for a http server: 
  // http.ListenAndServe(":3000", func (w http.ResponseWriter, r *http.Request) {
  //   db.Find(...)
  // })
}

Behind the scenes, gorm.Open() uses https://golang.org/pkg/database/sql/, which is threadsafe and handles connection pooling for you. Don't call gorm.Open() every request. Call it once when setting up your application, and make sure you use defer db.Close() so connections are cleanly ended when your program exits.

gsanchietti added a commit to gsanchietti/dartagnan that referenced this issue Apr 16, 2018

athos. reuse same db connection
Avoid error:
  panic: pq: sorry, too many clients already

References:
- jinzhu/gorm#1427
- jinzhu/gorm#1053
@QianYu92

This comment has been minimized.

Copy link

commented May 9, 2018

But here: http://go-database-sql.org/retrieving.html it says if you don't Close a Query connection it would keep as open so you should defer rows.Close() it. How should we do here?

@g10guang

This comment has been minimized.

Copy link

commented Oct 27, 2018

@stretchkennedy OS wil automatically clean any socket connection after process exit. So I think defer db.Close() is not needed.

@stretchkennedy

This comment has been minimized.

Copy link

commented Oct 28, 2018

@g10guang db.Close() can do a lot more than just cleaning up socket connections. For example, the go-sqlite3 driver calls sqlite3_close_v2, which does a lot of things including running fsync and getting rid of temporary journal and wal files.

Even if running cleanup code is currently unnecessary, it's generally a bad idea to leave it out, because the next version of a library could change the implementation.

@g10guang

This comment has been minimized.

Copy link

commented Nov 2, 2018

@stretchkennedy Thanks.馃槃

@Overover1400

This comment has been minimized.

Copy link

commented Nov 10, 2018

what will happen if we don't use "db.close" or " defer db.close"?(it's will close auto?)

@bjm88

This comment has been minimized.

Copy link

commented Nov 10, 2018

you should call db.close for DB's sake as well, it is still maintaining a connection and will eventually time it out if no keep alive activity, but not a good practice to rely on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.