Submitted by: @mrotteveel

Relate to JDBC291
Relate to JDBC207

Bad connection management by the user could leave too many connections open or for too long. In CORE3671 this resulted in an AV in Firebird embedded (due to a problem in embedded), in other cases it can result in a number of error 10054 (windows) or 104 (Linux) (connection reset by peer) in the firebird log.

It would be a good idea to have some additional cleanup of unclosed resources by the driver. Potential ideas:
* Using PhantomReference (or something similar) to track FBConnection and destroy the associated FBManagedConection when the Connection goes out of scope
* Adding a shutdown hook to close connections that weren't closed before shutdown (potentially risky, might clash with suggestion below for JavaEE)
* Adding a ServletContainerInitializer (for servlet 3.0) to 1) close remaining connections and 2) unregister the driver (see also http://stackoverflow.com/questions/8514725/getting-a-timer-in-a-javaee-friendly-way-that-works-on-javase-too-for-use-in-a ) and/or add means for a developer to get Jaybird to cleanup (eg for pre-servlet 3.0)
* Provide logging when unclosed resources are forcefully closed by the cleanup

There is also a need to review the locations where Jaybird creates threads and eliminate that as much as possible eg by replacing those with a single-threaded ScheduledExecutorService. I believe that most of the additional threads are created in the org.firebirdsql.pool package and part of that package is getting removed in 2.3 (the connection pools; see JDBC93 and related issues), so this might be less important.