FIX: Cancel statement before closing to avoid leaking connections

[jonasPoehler]

Situation: Trying to close busy connections, we first have to close the statements which have run and might currently be running over the connection. For DB2 we first have to call cancel on the statement, in order for it to actually stop and the executing thread to be notified.

[rPraml]

Situation: Trying to close busy connections, we first have to close the statements which have run and might currently be running over the connection.

When does this exactly happen? During shutdown?

For DB2 we first have to call cancel on the statement, in order for it to actually stop and the executing thread to be notified.

Under normal conditions, the pool should never try (expect on shutdown) to close busy connections while there is still a query running.

So I also think, that this recovery strategy (which sounds legit) will hide also the real error (e. g. statement/connection is put back to pool, while there is a query running). I'm happy to get more details here the next few days

[jonasPoehler]

When does this exactly happen? During shutdown?

Shutdown is one situation, the other one is the heartBeat. The heartBeat has a method testConnection() which tries to acquire a connection from the pool to run a isValid-Test on it. If either the acquiration or the validation fails, it runs notifyDataSourceIsDown which calls reset() on the pool which itself closes connections older than leakTimeMinutes (default 1 minute). This will close connections which might still be running statements.
The next issue (not covered by this PR) is that the heartBeat doesn't distinguish between the connection pool being exhausted (all connections in use) or the connection to the database being lost. Both trigger the same behaviour (notifyDataSourceIsDown).