Go / Golang sql.DB在函数中重用 [英] Go/Golang sql.DB reuse in functions

查看:147
本文介绍了Go / Golang sql.DB在函数中重用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

sql.Open()返回一个类型为* sql.DB的变量

我有一个函数可以调用其他所有需要进行数据库调用的函数

p>

是否更正确/有效:


  • 发送* sql.DB指针到每个函数,或
  • 在每个函数中创建一个新的* sql.DB对象


    意义

      func DoLotsOfThings(){
    db,_:= sql.Open()
    defer db .Close()
    DoTask1(db)
    DoTask2(db)
    }


    $ b $ ()



    $ $ $ $ $ $ $ $ $ $ $ $ $ $ $

    $ b func DoTask1(){
    db,_:= sql.Open()
    defer db.Close()
    }

    func DoTask1(){
    db,_:= sql.Open()
    defer db.Close()
    }

    我之所以问这个问题,是因为我目前正在向每个函数发送指针,而我的驱动程序似乎打破了。我使用的是 http://code.google.com/p/odbc ,这使我相信每个功能都应该有它自己的,我可以依靠司机的内部。



    编辑



    < RE驱动程序破坏,它只发生在高流量的环境下。它只发生在说,十分钟左右的时间。这导致我相信有某种内存泄漏使得使用该驱动程序停止工作。然而,我推迟db.Close()为每个* sql.DB实例,所以我不知道我能做些什么来解决这个问题。



    andybalholm说连接池在内部处理,这似乎是准确的,因为它只会在我尝试执行某些事情时中断,而不是在调用sql.Open()时发生中断。



    如果我让我的Go应用程序继续运行,它将无法执行任何类型的SQL查询,但是如果我尝试单独连接到MSSQL并运行查询来运行其他Go测试,则它可以工作。

    解决方案

    您不需要在整个地方打开数据库连接。数据库/ sql包在内部执行连接池,根据需要打开和关闭连接,同时提供可以同时使用的单个连接的幻想。



    可能需要在其他地方寻找你的司机损坏的原因。有关这方面的更多细节将使人们更容易了解发生了什么。


    sql.Open() returns a variable of type *sql.DB

    I have a function that calls 10 other functions that all need to make database calls

    Is it more correct/efficient to:

    • Send the *sql.DB pointer to every function, or
    • Create a new *sql.DB object in each function

    Meaning

    func DoLotsOfThings() {
        db, _ := sql.Open()
        defer db.Close()
        DoTask1(db)
        DoTask2(db)
    }
    

    or

    func DoLotsOfThings() {
        DoTask1()
        DoTask2()
    }
    
    func DoTask1() {
        db, _ := sql.Open()
        defer db.Close()
    }
    
    func DoTask1() {
        db, _ := sql.Open()
        defer db.Close()
    }
    

    The reason why I'm asking is because I am currently sending the pointer to each function and my driver seems to break. I'm using http://code.google.com/p/odbc , which leads me to believe each function should have its own, and that I can rely on the driver's internals.

    EDIT

    RE driver breakage, it only happens under high traffic environments. And it only happens after say, ten minutes or so of time. Which leads me to believe that there is some sort of memory leak that makes using the driver stop working. However I defer db.Close() for every instance of *sql.DB, so I don't know what else I can do to resolve this issue.

    andybalholm says the connection pooling is handled internally, which seems to be accurate, because it only breaks after I attempt to execute something, not when I invoke sql.Open()

    If I leave my Go app running, it will not be able to execute any sort of SQL queries, but if I attempt to run other Go tests separately connecting to MSSQL and running queries, it works.

    解决方案

    You shouldn't need to open database connections all over the place. The database/sql package does connection pooling internally, opening and closing connections as needed, while providing the illusion of a single connection that can be used concurrently.

    Probably you need to look elsewhere for the cause of your driver breakage. Some more details about that would make it easier for people to figure out what is going on.

    这篇关于Go / Golang sql.DB在函数中重用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆