optional keepAlive configuration param

[titaniumlou]

allow users to specify an optional keepAlive parameter that will issue the query 'select 1' every keepAlive milliseconds so the schema-maintained connection does not get closed due to the MySQL server's idle connection timeout

[dgsan]

I know people have had trouble with timeouts/disconnectes, resulting in stuff like the solution in this issue thread which has never been turned into a pull request: #36

I'd prefer there were a unit test, but at the same time it seems like this is something it'd be hard to write a unit test for.

[titaniumlou]

I think it's important to account for what might happen "behind-the-scenes" to the connection that is stored
as schema.client.

Two possible tests come to mind:

• mock the database connection and close it after some inactivity timeout. With the keepAlive setting the mock database should never detect the schema's connection as being inactive long enough to be closed due to inactivity.
• make sure the schema re-establishes it's connection if it detects that the server has closed the connection due to inactivity (or some other recoverable 'error' condition)

From the library user's perspective it's not obvious that the schema creates (and stores a reference to) a connection to the database, so I think it's a bit unreasonable to expect the library users to account for the inner-workings of the schema.

[dgsan]

So I'll wait for your tests, then.

[mscdex]

It's better to use DO instead of SELECT, like 'DO 0;', since it doesn't result in any rows being sent to the client.

EDIT: Or better yet, just use the driver's ping() method which actually sends a special packet (COM_PING) just for this purpose and thus does not even execute any kind of query.

[titaniumlou]

@mscdex the ping() or 'DO 0;' method sounds like a good improvement to me, did you happen to commit those changes anywhere? or have them locally? 👍

[mscdex]

@titaniumlou Unfortunately no, I just happened to stumble upon this issue when looking at jugglingdb.