I\'m reading a code from the last developer that worked on the system and he never closes any connections with the database. He only closes PreparedStatement
an
There is no good reason for this, it will result in a very brittle application. It's easy for a database connection to go stale if there's a network problem or if the database doesn't respond for a little while, and with the reliance on a single existing connection there's no recovering without restarting the application.
There are other bad points to this. For instance, typically connections are synchronized so if a web application with multiple concurrent users was built this way it would limit the concurrency of the application. But the inability of your application to recover from transient problems is enough to make this worth fixing.
He is likely using the same connection to do all SQL processing. That's not a bad technique; but, if he didn't write the code for a clean shutdown, then it can be difficult to know when to close the only connection.
So I'll wager that this code's rationale is to let the process die, let the socket die as a result of that, and then let the remote database eventually clean up the connection. Does it work, yes. Is is nasty and a place where problems can easily occur, yes.
The way to fix this is to find your main loop. The one that keeps running. Then you need to control the shutdown by putting the shutdown logic just after the main processing loop. Finally, you'll need to scrub the code of all System.exit(...)
calls.
I'm assuming that since you mentioned the code was inherited, it was Java 1.6 or lower. In the 1.7 and beyond, you can implicitly close a Closeable
when using it in the try with resources
language construction.
The documentation for Connection states that it extends AutoCloseable.
The documentation for AutoCloseable states that a class extends it when it is a "A resource that must be closed when it is no longer needed." It offers a Close method, and your friend should use it.
ResultSet
also extends AutoCloseable
, but PreparedStatement
does not.