Yes, I'd like to have a 'drain' event. I was thinking about it already when starting to work on a connection pool, but didn't have time to continue with it.

So if you want to add a 'drain' event for now, please send me a patch and I'll merge it.

I don't want to add 'pauseDrain' / 'resumeDrain' quite yet so - this use case would be better served by explicitly releasing connections from the pool. So my pool API would probably be like this:

Explicit alloc / free:

var connection = pool.alloc();
// do stuff
pool.free(connection);

Auto free:

pool.alloc({autoRelease: true});
// do stuff

What do you think?

Specifying the auto-release behaviour when checking out a connection seems reasonable, but I'd argue for {autoRelease: true} being the default, since the scenarios where you want to hang on to a specific connection are less common.

To be perfectly honest, my interest in having connection pooling be part of the mysql driver is pretty low, as I'm working on a very minimal layer over mysql, postgres, and sqlite3 that will provide a consistent interface for creating a connection pool, checking out connections, and making queries.

Specifying the auto-release behaviour when checking out a connection seems reasonable, but I'd argue for {autoRelease: true} being the default, since the scenarios where you want to hang on to a specific connection are less common.

My concern is that this default will lead to a lot of subtle programming errors. Example:

a) User allocates a connection (set to auto release by default)
b) Performs a query
c) Inside the query callback performs an http request
d) In the http request callback performs another query
e) Oh shit, the connection was already auto-released after c)

To be perfectly honest, my interest in having connection pooling be part of the mysql driver is pretty low, as I'm working on a very minimal layer over mysql, postgres, and sqlite3 that will provide a consistent interface for creating a connection pool, checking out connections, and making queries.

I find connection pooling to be a surprisingly difficult feature. You're an ambitious man for trying to abstract it across drivers.

e) Oh shit, the connection was already auto-released after c)

Yeah, on second thought this is likely to be way more common than I imagined. Backing up a bit, I think the real issue is in trying to shoe-horn the pooling semantics into the connections themselves. What if your pool interface had a query method, and using that method directly on the pool is how a user indicates they want auto-release behaviour? e.g::

connection = pool.alloc() // I want a connection, I'll give it back when I'm done
pool.query(function (err, rows) {
  // the user never sees the connection used, so auto-releasing it is a non-issue.
})

That's quite similar to how gesundheit engines behave right now, and it's working pretty well for me there.

I find connection pooling to be a surprisingly difficult feature. You're an ambitious man for trying to abstract it across drivers.

Writing a DB agnostic library means I'm already committed to writing a bunch of shims for any driver I want to support, so factoring that into a separate module just seems like an obvious next step ;)

Yes, I was planning on having a pool.query() method for exactly this use case. I'll soon have some time to work on node-mysql again, so please keep me posted on your pool.

I've started on it over here, but unfortunately there is very little documentation or tests so far, I'm just testing the feasibility of the idea.

FWIW, my main use case for this (querying with pooled connections and not having to manually return them) is now implemented by my any-db project. I need to start expanding the test suite now that I'm somewhat satisfied with the design, but for now it "works for me" and I no longer need the 'drain' event proposed here and in #272.

Looking at #306, I'm not sure that the use case as presented warrants increasing the API surface area of the driver, but I'll pick that discussion up over there.