We are using tomcat jdbc connection pooling with Oracle database.
Recently, we encountered problem that there are too many inactive session in Oracle database from JDBC THIN CLIENT.
Can anyone help us in this? Why is it causing inactive session in the database and what can be the solution to this.
Thank you.
Adjust settings of your pool, following the documentation. Setting maxIdle and minEvictableIdleTimeMillis to low values would ensure that idle connections are evicted fast, and that few idle connections stay open. Obviously, it will also make your pool less efficient, since connections will be closed and opened more frequently.
If you are getting SQLExceptions because connections have timed out, you should set a validationQuery (to something like SELECT 0 FROM DUAL) and your connections will be tested before they are checked-out of the pool. Any connection that has failed will be replaced by a working connection and then returned to your code.
Related
When our application tries to connect Oracle database, this exception is thrown:
java.sql.SQLRecoverableException: Connection has been administratively disabled by console/admin command. Try later. java.lang.Exception: It was disabled at Tue Oct 20 23:55:14 CEST 2015
But, from Weblogic console the connection test returns OK.
Weblogic version: 12.1.3.0.0
Any explanation is welcome. Thanks
The reason the test works is because that is creating a connection and running a test query. That is not what your code is doing when it is using the data source in an ejb. The code is going through the connection pool and that is what has been marked as bad. There is no solution provided by Oracle that I have found except to: restart the server and that will re-enable the connection pool.
I suspect you have "Test connections on reserve" set because that is when this usually arises. What Weblogic does is: before it returns a connection from the pool it will run a test query, if the test query fails it waits and runs it one more time. If the query fails again it marks the connection as unhealthy. If all the connections in the pool become unhealthy it will mark the pool as disabled and gives you the error message you see: 'Connection has been administratively disabled by console/admin command. Try later.'
In regards to the 'Try Later' part of the error message, as far as I can tell Oracle is wrong about trying again later. I have never seen it recover later.
I'd like to share this article that help me out to understand better my problem:
https://www.techpaste.com/2012/09/connection-administratively-destroyed-reconnect-oracle-weblogic-server/
The “java.sql.SQLException: Connection has been administratively destroyed.” is expected:
the DB was shutdown; even if it was restarted later, the JDBC connection are pointing to DB processes
that have been destroyed.
You need to restart your WebLogic Server to recreate new JDBC connections.
All the current transactions are lost, as the database was shutdown.
High availability of your RDBMS is required to minimize this issue.
Is there any other error before that one ?
Maybe in the log you can find that connection is been closed.
You can avoid this by selecting "Test on Connection Reserve" in the datasource.
Does SQL Azure allow 3-rd party connection pool like HikariCP or BoneCP?
We configured HikariCP it works when we just run app but later db doesnt response on request. Is it HikariCP issue or it's common connection poool issue and no need spending more time on investigation?
HikariConfig config = new HikariConfig();
config.setMaximumPoolSize(50);
config.setDriverClassName(env.getProperty("jdbc.driverClassName"));
config.setJdbcUrl(env.getProperty("jdbc.url"));
config.setUsername(env.getProperty("jdbc.user"));
config.setPassword(env.getProperty("jdbc.pass"));
config.addDataSourceProperty("cachePrepStmts", env.getProperty("jdbc.cachePrepStmts"));
config.addDataSourceProperty("prepStmtCacheSize", env.getProperty("jdbc.prepStmtCacheSize"));
config.addDataSourceProperty("prepStmtCacheSqlLimit", env.getProperty("jdbc.prepStmtCacheSqlLimit"));
config.addDataSourceProperty("useServerPrepStmts", env.getProperty("jdbc.useServerPrepStmts"));
See this SQL Azure page re: Connection Constraints.
Maximum allowable durations are subject to change depending on the resource usage.
A logged-in session that has been idle for 30 minutes will be terminated
automatically. We strongly recommend that you use the connection pooling and
always close the connection when you are finished using it so that the unused
connection will be returned to the pool. For more information about connection
pooling, see Connection Pooling.
See if any of these errors match up to your logs. Search that page for "terminated" and "busy" to find error codes that might be relevant to your issue.
I would suggest setting the maxLifetime property in HikariCP to 15 minutes, and the idleTimeout to 2 minutes.
There is nothing on the SQL Azure side that would prohibit you from using a 3rd party connection pool. My guess is that the connection failed between the server and the client and the client didn't remove the connection from the pool.
Moving forward, I'd ensure that whichever 3-rd part connection pool you end up using tests that the connection exists before taking it out of the pool for use.
Hope that helps.
Hey I'm using Glassfish open source v4 and I'm having a weird problem.
I have defined a JDBC connection pool to Oracle 11g in the admin console and I've set :
Pool Settings
Initial and Minimum Pool Size: 500
Maximum Pool Size: 1000
Pool Resize Quantity: : 750
And I've created a specific user for this connection pool. Yet sometimes when I inspect opened connections in the database I see that there are more then 1000 (maximum I've seen was 1440)
When this happens any query attempts fail, sometimes with OutOfMemory exception, some show http thread interuptions and some don't show any logs at all, just takes a long time.
What I am wondering is how is it possible the Glassfish opens more connections then I've defined it to?
1t try to compare output from netstat on appl. server and db server side. You may have some "dangling" connections. Also try to find some documentation about DCD (Dead connection detection) in Oracle.
Few years ago I saw situations where Java application server thought that the connection is dead because it is not responding for few minutes. So this connection was put onto some dead connection list and a new connection was created.
There also can be some network issues - for example there is a FW between appl and db server.
When TCP connection is not active for one hour then it's cut over on one side but DB sever does not know about that.
The usual way how to investigate that is
compare output of both netstat(s) (appl./db)
identify dangling TCP connections
translate TCP connection onto Unix process id(PID) of Oracle session process
translate PID onto Oracle session (SID and SERIAL#)
kill the session on Oracle level (alter system kill session ...)
Someone told me if I set the "ValidateConnection" property in Oracle to TRUE, the application will be able to handle the following cases:
Timeouts on network equipment that shutdown TCP connections after a certain
amount of time and/or inactivity.
Physical connection breaks such as pulled cables, network equipment resets,
etc.
Oracle server being restarted, or DBA logically closing the connection on
the server side.
My questions are:
If ValidateConnection is set to TRUE, can oracle actually handle the above cases?
Do I need to write additional code or Oracle's connection pool will just wait until the connection is timedout?
What technique or tools can I use to test this cases? Sample code, or link to other article will be very useful.
Thanks.
ValidateConnection simply tells Oracle to test the connection from the pool prior to handing it to the application. This prevents you from getting already disconnected connections from the connection pool. To answer your question of which situations are handled by using ValidateConnection, I guess I would need to know what you mean by "handle". If the Oracle server has been disconnected from the internet, ValidateConnection cannot do anything about it. However, once it is back online, ValidateConnection will prevent Oracle from handing your application disconnected connections from the connection pool. The link below gives some a little more information, and he shortly describes how he tested ValidateConnection in his environment.
http://spdeveloper.net/2009/10/disconnected-odp-net-and-system-data-oracleclient-connections/
We are using ADO to access Oracle 10g release 2, Oledb provider for Oracle 10g. We are facing some issue with the connection pooling. The database reside on the remote machine and connection pooling is occuring as it should. But if the remote machine goes down for some reason, the connection is returned from the pool and query on that connection fails. When this connection is closed, it is returned back to the pool instead of being invalid. The subsequent connection opening requests are sucessfull but query fails. This is strange behaviour, according to OLEDB specifications, provider must support DBPROP_CONNECTIONSTATUS property, thus in case of invalid connection, it would not be returned back to the pool.
Things get weired when the remote machine comes up. The connections in the pool are still invalid and although the connection opening succeeds, query on the connection fails. Oracle OLEDB is unable to connect to the server anymore and we have to restart our application. Well this is undesired cause our application is a critical application.
Any ideas on how to get over this.
Thanks
Mubashir
If you are doing this programmatically, use a try block, so that if something does happen, it won't fail. With a try block, you can catch an exception and ignore it, so that the errors are shushed.
You could tell the pool to not accept invalid connections, by marking the connection invalid before it is returned to the pool.
Connections are recovered after 10 minutes by default. Time can be set by the registry key SPTimeout under the oledb provider's root key.
Actually the default connection pool timeout is 120 seconds at least for this Oracle 11 32-bit OLEDB installation. You can find the registry settings at:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Oracle\KEY_orac
Where KEY_orac is the KEY_<oracle_home_name>
The key name is ORAMTS_CONN_POOL_TIMEOUT and the default value is 120.
It does not appear that you can set connection pool parameters at the connection string level.
In most connection pool implementation it is possible to check the connection before using it. For example: you define a check query like select * from dual and if you pick up a connection from the pool this query will be executed. If it fails, then the connection will be excluded from the pool and a new one will be opened.