I recall having this problem several years ago; I still have the code in production which is catching SQLException and retrying the operation if the class name of the exception ends with "StaleConnectionException". Our server has been upgraded several times since I did that and I have no idea whether the retry code actually does anything any more. It isn't broken, it's a low-volume application used only by people in my department, so there's no reason to review it.
My impression is that I haven't had to deal with this problem since I wrote that application, so maybe connection pooling has improved since then. Anyway I would certainly agree with Martin that investigating configuration options to make the problem go away is likely to be a better idea than building workarounds into your code. In my case I only had
JDBC code in one place, so I only had to put my
hack protective code in one place. If there were 78 servlets all with JDBC code, or if I had an ORM dealing with the database, it would have been another question entirely.