在哪里销毁knex连接 [英] where to destroy knex connection

查看:390
本文介绍了在哪里销毁knex连接的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在 knex ="noreferrer"> pg .

I'm using knex with pg.

我有一个类似于以下项目.

I have a project similar as following.

dbClient.js

dbClient.js

const dbClient = require('knex')({
  client: 'pg',
  connection: {
    host: '127.0.0.1',
    user: 'user',
    password: 'password',
    database: 'staging',
    port: '5431'
  }
})

module.exports = dbClient

libs.js

const knex = require('./dbClient.js')

async function doThis(email) {
  const last = await knex('users').where({email}).first('last_name').then(res => res.last_name)
  // knex.destroy()
  return last
}

async function doThat(email) {
  const first = await knex('users').where({email}).first('first_name').then(res => res.first_name)
  // knex.destroy()
  return first
}

module.exports = {
  doThat,
  doThis
}

test01.js

test01.js

const {doThis, doThat} = require('./libs.js');

(async () => {
  try {
    const res1 = await doThis('user53@gmail.com')
    console.log(res1)
    const res2 = await doThat('user53@gmail.com')
    console.log(res2)
  } catch (err) {
    console.log(err)
  }
})()

如上所示从libs.js中删除knex.destroy()时. node test01可以输出res1res2.但是问题是连接无限期地挂起,而CMD永不返回.

When knex.destroy() was removed from libs.js as shown above. node test01 could output res1 and res2. But the issue is the connection hangs indefinitely and CMD never return.

但是,如果我从libs.js中取消注释knex.destroy(),则doThis将执行,由于doThis中不再有连接已关闭,因此CMD将挂在doThat上.

But if I uncomment knex.destroy() from libs.js, then doThis will execute, CMD will hangs at doThat as there's no connection anymore which has been closed in doThis.

我的问题是:

knex.destroy()的最佳位置是什么?还是有其他方法可以做到?

What is the best location for knex.destroy()? Or there's other ways to do it?

感谢您的时间!

推荐答案

Knex destroy()似乎是一次手术.销毁连接后,下一个操作可能需要一个全新的连接池.

Knex destroy() seems to be a one time operation. After destroying a connection, one might require a brand new connection pool for the next operation.

您导出的db客户端模块将缓存到节点模块缓存中,并且不会在每次需要时创建新的连接池.

The db client module you export is cached into node module cache and a new connection pool is not created every time you require it.

这是预期用途,应在应用程序退出或完成所有测试后销毁该池.如果您有理由为每个操作创建/销毁连接(例如在无服务器环境中),则不应重复使用已销毁的客户端,而应每次都创建一个新实例.

This is intended usage, the pool is supposed to be destroyed when app exits or all the tests are done. If you have reasons to create/destroy connections for every operation ( like in serverless environment) you should not reuse the destroyed client, rather create a new instance every time.

否则,它违反了连接池的目的.

Otherwise, it defeats the purpose of connection pooling.

更新有关无lambda/无服务器环境:

Update about lambda/server-less environments:

从技术上讲,应在lambda函数运行后释放函数及其资源,这包括它可能已打开的所有连接.这对于真正的无状态功能是必需的.因此,建议在完成功能后关闭连接.但是,打开/关闭大量连接的许多功能最终可能会使数据库服务器用尽连接(请参阅 PgBouncer 协商数据库服务器和Lambda函数之间的连接.

Technically a function and its resources are to be released after the lambda function has run, this includes any connections it might have opened. This is necessary for truly stateless functions. Therefore it is advisable to close connection when function is done. However, a lot of functions opening/closing a lot of connections may eventually make the DB server run out of connections (see this discussion for example). One solution might be to use an intermediate pool like PgBouncer that negotiates connections between DB server and Lambda functions.

另一种方法是让平台提供商(AWS)向lambda环境添加特殊的池化功能,并让它们共享长期存在的资源.

The other way is for the platform provider (AWS) to add special pooling capabilities to lambda environment and let them share long-lived resources.

这篇关于在哪里销毁knex连接的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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