Mysql: The difference between release and destroy (for connection)?

Created on 26 Jul 2016  路  3Comments  路  Source: mysqljs/mysql

Sorry for bringing up such issue, but I really have difficulties seeing when one should call destroy and release on connection. I know theory, but in practice release is not terminating command, so in the effect program hangs. It seems its practical usage is very limited. See my SO question:

http://stackoverflow.com/questions/38490440/when-you-call-release-instead-destroy-on-connection

(I still didn't do the tests mentioned in the answer).

Today I tried to understand the management of the connections in the pool, i.e. how safe is to use pool.query directly. There is an old topic: https://github.com/mysqljs/mysql/issues/857#issuecomment-47382419

So I dig up a bit and found out, that pool.query uses release on close (not destroy). I run very simple test case:

db.pool.query("Select COUNT(*) AS count from word", function(err,rows) {
  if (err)
    return next(err);

  console.log(rows[0].count);
});

In my case I have table word, feel free to put any table you have, with or without data. The point is such simplistic code leads to non-terminating program.

So either I don't understand something or there is some flaw with release. For the record, the issue with "pool.query vs. pool.getConnection" I linked above has the code with conn.release() so I believe it also translates to non-terminating program.

FAQ

Most helpful comment

your concern about "non-terminating program" suggest that you are writing a script that supposed to run some queries + do some calculations and exit. In that case you probably don't need pool.

Connections are relatively expensive (time: tcp connection + 3 roundtrips until first response to query; CPU, server side: mysql creates full thread per each new connection, and usually max number of allowed connections is very limited). For that reason it makes sense to allow to say "I'm done querying this connection, but if it's required later - don't close it now and mark as available". This is what conn.release() for

The point is such simplistic code leads to non-terminating program.

You need to tell that your program is ready to terminate: close your servers, your open tcp connections etc. With pool there is pool.end() for this - https://github.com/mysqljs/mysql#closing-all-the-connections-in-a-pool

All 3 comments

your concern about "non-terminating program" suggest that you are writing a script that supposed to run some queries + do some calculations and exit. In that case you probably don't need pool.

Connections are relatively expensive (time: tcp connection + 3 roundtrips until first response to query; CPU, server side: mysql creates full thread per each new connection, and usually max number of allowed connections is very limited). For that reason it makes sense to allow to say "I'm done querying this connection, but if it's required later - don't close it now and mark as available". This is what conn.release() for

The point is such simplistic code leads to non-terminating program.

You need to tell that your program is ready to terminate: close your servers, your open tcp connections etc. With pool there is pool.end() for this - https://github.com/mysqljs/mysql#closing-all-the-connections-in-a-pool

Thank you very much, so non-terminating state is intentional and has its purpose.

I am closing this topic then, because as for me, it is clear now. Once again -- thank you!

Yes, this is the main use case for (any) pool - re-use things later (because they are relatively expensive to create and not so much expensive to keep ) = memory allocation pools, thread pools, process workers, tcp connections and many other things can be pooled

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hohozhao picture hohozhao  路  4Comments

flowl picture flowl  路  4Comments

DmitryEfimenko picture DmitryEfimenko  路  4Comments

wahengchang picture wahengchang  路  3Comments

whatthehell232 picture whatthehell232  路  3Comments