Connection pools slap a façade over the
JDBC driver.
For
most JDBC functions, the façade driver merely passed through to the actual driver specified in the pool definition.
The one exception is the close() method. That one returns the Connection to the Connection Pool. It does
not close the actual JDBC connection.
If you do not close the connection when you are done using it (preferably as soon as possible), then you will leak connections all over the landscape and eventually empty the connection pool. If you punch past the pool connection façade and invoke the actual JDBC close() method, then the physical connection to the database will be severed and the pool connection will be damaged with unpredictable results on the next task that pulls that particular connection from the pool.
The reason for connection pools is that physical connections are expensive in terms of time and resources to establish. So rather than make-and-break for each use, it's better to recycle connections that are already established. The connection pool contains these connections.
An additional note:
never store a Connection as a Session object. it's an
interface, not a class, and it's not guaranteed serializable. Even if it was, you'd be robbing the pool of resources, because once checked out of the pool, it's unavailable to other users.