I need your help. I use hikariCP for pool connection and i get someone throuble when i create a query to DB. Connection is established and at DB occur process but response timeline is long about two hours and i want close connection manually. I set timeout config.setConnectionTimeout(TimeUnit.MINUTES.toMillis(2L));
but it not help. It set time for try to connection only but not set time for query and time to get response. How i can manually close connection ?
I am still unclear what you are trying to do.
If you want the query to timeout, call Statement.setQueryTimeout() before your long query.
If you simply want the connection to actually be closed when you call Connection.close(), rather than returning to the pool, with such a long query that is going to happen already.
Why? Because the default maxLifetime is 30 minutes. So, if you get a connection from HikariCP and use it for 2 hours, it is going to be well past its lifetime. Therefore, when you call Connection.close() HikariCP will immediately evict it from the pool (i.e. close the actual DB connection).
Related
In our code (which runs as a schedule job via timer), we have threads running in parallel to perform a database operation. Problem here is each thread is initiating a connection via Hibernate factory. These connections are closed after every database action but stil gets stocked in the connection pool(as INACTIVE). All the connections gets released only after the job/main process is killed.Is there any way to release the connection even from connection pool after the database operation. When we use cron job instead of timer, the process gets killed automatically but we dont need cron here.
Kindly help us to resolve this as we are already nearing production release.
Note : We came to know about this when QA tested with heavy load on the job and for each load new connections are pulled.
You need to restrict the number of threads getting created in the thread pool.
dotConnect for Oracle uses connection pooling. The OracleConnection connection string has the Pooling parameter. If Pooling=true (the default value), the connection is not deleted after closing it, it is placed to the pool instead. When a new connection with the same connection string is opened, it is taken from the pool (if there are free connections) instead of the creating a new one. This provides significant performance improvements. If you use 800 connections that are connected for 10-15 seconds each, and there are only few different connection strings, you may not have 800 actual connections. Closed connections will be placed to the pool, and they will be taken from the pool when a new connection with the same connection string will open. No additional connection will open in such case.
You can disable Pooling by adding 'Pooling=false' to the connection string. In such case, a connection will be deleted from memory and free the session. However this may lead to performance loss.
Most likely, pooling should not cause creating too much sessions. Try testing your application with pooling on. If the session number will be too large, you can disable pooling.
For more information, please refer to http://www.devart.com/dotconnect/oracle/docs/FAQ.html#q54
I have found the root cause for the issue and have also found the solution.
The root cause was number of connections set as minimum and maximum and the time out parameter.
The minimum was 5 and max was 20 and timeout was 800 seconds. But out job was scheduled to run every minute. Due to the configuration, the connections were not released properly within minute.
Another issue was our code was not using the session factory as singleton, but was initializing for each thread. Since the resource was not shared, each session factory creates 5 connections by default and extended to 20 max. Since the timeout also was higher before the connections are released, next set of job starts and creates its own set of new connections.
Finally the pool gets full and oracle becomes unavailable.
We fixed this by sharing the session object across and also setting the timeout to lesser value so that connections are getting released from pool.
I am having lots of connection problems when working with Microsoft server and creating the connection from java.
I need to communicate with db in average every 2 sec, for verity of things. Most of my queries are within the 500 milliseconds.
About every 15 min or so, I am having a connection drop and one of my queries is failing. I got a retry mechanism, that always work within 3 tries.
My only problem is that, 500 milliseconds query turns to be 2 sec or longer when there is a connection drop.
What would be the best approach of connection to SQL server, the way I do it now:
create Connection
create Statement
execute it
and close both the statement and the connection
Or should I keep the connection opened and only create multiple statements for each of my queries?
Let us take one issue at a time, first the Connection.
Connection to a database is resource intensive, to create and to hold on to. It would be wiser to create a pool of connections and hold on to them until your application stops. A connection pool manager may be of great help in this context. I have personally used Apache's DBCP and found to be convenient and efficient. There could other alternatives too. When you need a connection borrow one from the pool and return it when its use is complete.
I need help with jdbc driver for mysql. I need to set connection timeout. java claims it's done by setLoginTimeout of the DriverManager class. but this method seems to not work.
Whatever value I put, say 15 seconds: setLoginTimeout(15) it will always timeout after 10 seconds always. Even if I getLoginTimeout it always return 0.
Some will ask why I need this, it's because when I click a button that performs a CRUD, I need to show progress of whatever insert, delete, etc through a thread. but how do I do it since DriverManager.getLoginTimeout returns 0 seconds but when run its actually 10 seconds.
I really need help, i have been searching all over, some say just setLoginTimeout but this method is not responding
The login timeout is not the same as a connection timeout. The login timeout (if supported by the JDBC driver) applies to creating a connection and logging in only and as you comment that you already use a connection pool, then this is not the property you are looking for.
To specify the connection timeout (or blocking timeout), you need to check the specific connection properties available for your JDBC driver, eg for Connector/J it is socketTimeout.
Also be aware that the configuration of your server may also influence how long the actual timeout may be.
Is there a way to close JDBC connections after a set timeout period? These connections are being created in a GenericObjectPool. I know the pool can close idle connections in the pool, but what about connections that are thought to be active? I am trying to control connections leaks in the event someone doesn’t call close(). From what I have read the only way may be to set a timeout period on the server, but I am hoping to find a way in Java. Thank you!
I agree with Peter Lawrey that I would make sure to close the connection always. But if I still have to ensure that a connection is closed (if someone took it from the pool and forgot to return it), I would do it as follows:
Decorate the java.sql.Connection that is returned by the pool.
Create a timer in the constructor and set it to duration configured, to tolerate with active connections.
If the user calls close on it before the timer fires, I will cancel the timer and return the connection to the pool.
If the timer fires before the connection is closed by the user, I will return the connection to the pool and invalidate the decorated connection so that further calls will throw IllegalStateException.
I was using the old Apache commons pool, but I switched over to the new Apache Tomcat Pool This actually has a feature to remove connections after a timeout period.
removeAbandoned - (boolean) Flag to remove abandoned connections if they exceed the removeAbandonedTimout. If set to true a connection is considered abandoned and eligible for removal if it has been in use longer than the removeAbandonedTimeout Setting this to true can recover db connections from applications that fail to close a connection. See also logAbandoned The default value is false.
As per my understanding, JDBC Connection Pooling (at a basic level) works this way:
create connections during app initialization and put in a cache
provide these cached connections on demand to the app
a separate thread maintains the Connection Pool, performing activities like:
discard connections that have been used (closed)
create new connections and add to the cache to maintain a specific count of connections
But, whenever I hear the term "connection reuse" in a JDBC Connection Pooling discussion, I get confused. When does the connection reuse occurs?
Does it means that Connection Pool provides the same connection for two different database interactions (without closing it)? Or, is there a way to continue using a connection even after it gets closed after a DB call?
Connection pooling works by re-using connections. Applications "borrow" a connection from the pool, then "return" it when finished. The connection is then handed out again to another part of the application, or even a different application.
This is perfectly safe as long as the same connection is not is use by two threads at the same time.
The key point with connection pooling is to avoid creating new connections where possible, since it's usually an expensive operation. Reusing connections is critical for performance.
The connection pool does not provide you with the actual Connection instance from the driver, but returns a wrapper. When you call 'close()' on a Connection instance from the pool, it will not close the driver's Connection, but instead just return the open connection to the pool so that it can be re-used (see skaffman's answer).
Connection pooling reuses connections.
Here is how apache dbcp works underline.
Connection poolableConnection= apacheDbcpDataSource.getConnection();
Apache DBCP implementation returns connection wrapper which is of type PoolableConnection.
poolableConnection.close();
PoolableConnection.close() inspects if actual underlying connection is closed or not, if not then it returns this PoolableConnection instance into connection pool (GenericObjectPool in this case).
if (!isUnderlyingConectionClosed) {
// Normal close: underlying connection is still open, so we
// simply need to return this proxy to the pool
try {
genericObjectPool.returnObject(this); //this is PoolableConnection instance in this case
....
}
My understanding is the same as stated above and, thanks to a bug, I have evidence that it's correct. In the application I work with there was a bug, an SQL command with an invalid column name. On execution an exception is thrown. If the connection is closed then the next time a connection is gotten and used, with correct SQL this time, an exception is thrown again and the error message is the same as the first time though the incorrect column name doesn't even appear in the second SQL. So the connection is obviously being reused. If the connection is not closed after the first exception is thrown (because of the bad column name) then the next time a connection is used everything works just fine. Presumably this is because the first connection hasn't been returned to the pool for reuse. (This bug is occurring with Jave 1.6_30 and a connection to a MySQL database.)