Develop Reference

How to reset a JDBC Connection object?

How to reset a JDBC Connection object (that is, a java.sql.Connection object)?
I have explored the concept of connection pooling. When a connection pool is used, a Connection object can be recycled. But how can a connection pool recycle a Connection object? I think that a connection needs to be "reset" (for example, if it is in a transaction, then perhaps rollback it, but there may be more things to reset) before it can be reused. But I cannot find such a "reset" method in the Java documentation about the class java.sql.Connection.

If you are talking about what you as a user of a connection should do, then that is simple: call close() on the connection. Closing the logical connection will signal to the connection pool that the connection is available for reuse, and the connection pooling manager is then responsible for performing the necessary reset, invalidation of statement handles, etc.
If you are talking about what you as the implementer of a connection pooling manager should do, that is where things become complicated.
Historically, JDBC provides no way to 'reset' a java.sql.Connection, other than by your own code (or your third-party connection pool) remembering the initial configuration, and restoring it after use, and keeping track of objects like statements and result sets and closing them when the connection is returned to the pool.
Originally, the intended way to reset connections in JDBC was for an application server to use a driver's javax.sql.ConnectionPoolDataSource as a factory for javax.sql.PooledConnection objects. These PooledConnection objects serve as handles for physical connections to be held in a connection pool (to be clear, ConnectionPoolDataSource is not a connection pool, it is a data source for a connection pool). The application server would then expose a javax.sql.DataSource handing out logical Connection objects, where on Connection.close(), the driver specific implementation of PooledConnection would take care of any necessary reset of a connection (though JDBC underspecifies what is 'necessary').
However, in practice this route is hardly ever used because support in drivers was (and often still is) spotty, inconsistent or downright incorrect, and JDBC wasn't clear enough on exactly what needed to be done when the logical connection was closed. The world has also shifted to using third-party connection pool libraries that do not use ConnectionPoolDataSource.
JDBC 4.3 (Java 9 and higher) introduced the methods Connection.beginRequest() and Connection.endRequest() to be called by connection pooling managers, which would seem to fit such pattern, but unfortunately JDBC 4.3 doesn't actually specify what kind of things an implementation should or should not do in response to beginRequest and endRequest.
In short, there is no real general way to reset a connection in JDBC.

Do you try to close() method and reinitialize Connection object again.
close()
Releases this Connection object's database and JDBC resources immediately instead of waiting for them to be automatically released

Connection pool with single connection vs connection for infrequent queries

I am building a Java application which queries my SQL server once a minute. Right now, the application is using a connection pool with a single connection (min pool size 1, max pool size 1).
I figured that a pool size of 1 would be enough because of the infrequent queries (once a minute, as mentioned before).
Do I need a connection pool at all, and if the answer is yes, is 1 connection enough? Or should I just not use a pool and open a new connection every minute?

using a connection pool with a single connection (min pool size 1, max
pool size 1).
In such case don't see any need or benefit of using connection pool since at any point in time there will be only one connection object and if it's in use then other request has to wait (or) create a non-pooled connection object.
Connection pooling is generally used to save time/resource from creation/tearing-up the connection object.
In your specific case, you can probably create a connection instance and dispose it off once done with your work.

I would like to give some reason to use the connection pool, potentially with multiple connections. Not sure if you are considering this negative case.
In real world, a query might run more than 1 minute with various reason.
Do you want the application to wait for the hung connection? Or what is your expected behavior for this?
Also if you use connection pool, DB connection initialize process(time and resource consuming) is done while the pool is generated. When you actually use the DB connection pool, some of initialization step should be already done so it reduce repetitive overhead when the application is running query.

If you're accessing the database that rarely, then in practice having a connection pool will not provide any significant benefit. However, I'd keep it if it's already written. Maybe one day your application will grow and you'll find the pool useful. It's not a bad thing to have.

Best approach for returning connection objects to HikariCP pool

I am trying to use HikariCP connection pool. I was able to get it to work and get a connection that I could use. I am not sure what is the best approach for returning the connection to the pool.
I have the following questions:
Should I close the connection when I am done, rely on idleTimeout
and maxLifetime settings or is there another call that I can use so
as not to hog the connections from the pool?
If I close the connections (instead of returning to the pool), would
that not result in additional connection objects being created
to meet the requirements of the connection pool size?
Looking for helpful suggestions.

As with most connection pools, Hikari doesn't give you an actual JDBC Connection when you ask for one. What it does instead is give you a proxy that implements the Connection interface. In the case of Hikari - it's a ConnectionProxy object.
This proxy serves a few purposes, the main of which is - take the control of opening/closing connections and statements away from you and into the connection pool. This happens automagically and you should be using your connections as usual. This includes closing them after use.
If you look at the source code for Hikari, at the ConnectionProxy class in particular, you will see that the close() method is very different from the standard one. The code reads as:
Mark the connection as closed, do cleanup, reset underlying connection state and params.
Hence, simply calling close() will just clean and return the connection to the pool.

Is it necessary to explicitly close connections in Tomcat JDBC pool?

Example code in "http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html" explicitly closes a connection after it is used.
However according to my understanding, should not it be the connection pool's responsibility to manage active and idle connections?
Why would not I want a connection to be re-used by another transaction?

You must close the connection so that you can release it back to the pool. The "Connection" you get from the pool does not, per se, represent the actual, physical connection to the DB. Rather it's a wrapper. So, closing the connection informs the pool that it is free for use by other clients of the pool.

You need to call Connection.close() to return the connection to the pool, it doesnt actually close the underlying connection.

connection pool for proprietary connection api (non jdbc)

I am using an API to connect to some hardware terminals and networks. The API allows me to connect to the servers, disconnect and interrogate for data, pretty similar to what JDBC connection allows you to do. Anyway, since this is not using the JDBC Connection interface, I cannot use a connection pooling already existing.
I would like to avoid writing one myself if I can use one already existing, or maybe just build a small adapter on top of that. Anyone knows of any framework/library that would allow me to enable connection pooling, that can handle my connections, can ensure that the connection is alive all the time etc?
I have looked at Commons Pool, but that only gives you a few classes to put/get your connections ... it doesn't do any of the maintenance tasks etc (check if connection is invalid from time to time, reconnect etc). I can add on top of that the mechanism of connection checking and reconnecting if any issues etc in case there is nothing out there that does this already.
Cheers, Stef.

Apache Commons Pool actually supports creating, destroying and checking objects for validity before handing them out with the PoolableObjectFactory class, which you use with the actual pool implementation by passing it as a parameter:
final PoolableObjectFactory objectFactory = new MyPoolableObjectFactoryImpl();
final ObjectPool pool = new GenericObjectPool(objectFactory);

You can look into dbcp http://commons.apache.org/dbcp/
it's BasicDataSource provide methods such as maxActive, maxIdle, maxWait etc check documentation for more
http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/BasicDataSource.html
interesting one if you are going for new implementation try tomcat 7 jdbc connection pool
http://people.apache.org/~fhanik/jdbc-pool/jdbc-pool.html
[edit] useless for the scenario -hGx so upvoting Henning's post