Testing for a healthy database

A Vaadin applications uses SimpleJDBCConnectionPool to connect to a mySQL database. The TableQuery class is used to move data in and out of SQLContainers. It all works perfectly under normal circumstances.

To make the deployment robust, I would like to handle gracefully the possibility that the database is not running when the Vaadin app starts, or the database shuts down while the application is running.

For example, starting the application with the database down produces a stack trace with this error when the first TableQuery is made in the Database helper class.

javax.servlet.ServletException: com.vaadin.server.ServiceException: java.lang.RuntimeException: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

No big surprise, but then the situation worsens. The Database class has started, the session to which my UI is attached seems to persist when the browser window is closed or refreshed. So if I restore the database and refresh the browser, operation is not recovered. My singleton Database class, evoked from the now closed UI persists, but is unable to provide database access because of the previous error. I have to restart Tomcat. Obviously this is not good - a user can’t do it.

I was hoping to catch the exception in the try/catch block and divert the user to a notification rather than the stack trace, but maybe it’s not as simple as that? Web discussions describe modifying the deployment descriptor. Can that be done in one of the servlet annotations or as an extension to Servlet class?

Edit: Or better yet:

if ( theDatabaseIsHappy ) { doTheDatabaseRequest; } else { don’tDoTheDatabaseRequest; tellTheUserTheDatabaseIsDown; }

What is the best way to test for a working database and gracefully advise the user - avoiding irrecoverable errors?

Vaadin 7.1.9, manual push, Servlet 3.0, Tomcat 7.0.47

I found a way to harden an application against a mySQL database going down, then up again. After cycling the database, subsquent use of the connection pool fails. This (brutal?) solution seems to work.

   try {
        int size = planeContainer.size();  // size is unused, other than as a test here
        } catch ( Exception e ){
            // close the connection pool using the destroy() method
            // re-establish the connection pool and rebuild tablequeries and sqlcontainers
            // continue using the connection pool as intended prior to the test
        }

Setting a variable to the sql container’s size throws an exception if the database has been down. So the catch block takes down the connection pool using the destroy() method then re-establishes it. The try/catch block is positioned at the first database access after a browser refresh, so the user can easily re-establish a working app after the database is back up.

Better methods welcome…