Can't reconnect JDBC with Oracle after session gets killed

Question

We have an application based on servlets here, and we are having a problem with it. Here's what's happening: after the time-out of oracle (like if we go home after work and try to login in the application next-day), we get a lot of errors and exceptions such as: connection closed, closed statement, and others.

A way to simulate this error is accessing oracle sessions as admin and killing the session in the middle of the use. Doing this, the same problem happens.

What we do is, we have a main project called system-proj that is the pre-requisite to all the other modules (set by maven), and we deploy all the .war files in tomcat.

The problem gets solved by restarting tomcat. Simple as that.

My question is, is there any way to reestablish this connection without restarting Tomcat ? Or else, if restarting Tomcat (or reloading a single .war automatically) is necessary, is there any way to do that?

I can't see where I'm wrong in that.

Answer 1

From your description I think you are using a database pool. Connection pools are pre-created bunch of DB connections that will be used, and re-used to serve multiple requests. During idle time, the database connections are timed-out on the database server, and gets invalidated, hence you get the errors after long periods of inactivity. When you restart Tomcat, you are re-creating new connections in the connection pool, which resolves the problem.

If you are using a database pool, then you can ping the database with a random query (like- 'select count(*) from tab' on Oracle) if a connection is not utilized for x minutes. x should be less than the idle connection timeout time of your database.

The other simpler solution is to open DB connection, perform DB operation and then, close the DB connection, rather than using a database pool. Since the connections are created on-demand you have no timeout issues. Though this is a simple solution, this may not be a viable solution as obtaining new connections would have some overhead.