This FAQ covers the basics of using Tomcat and JDBC together. It is based on questions that regularly appear on the pgsql-jdbc mailing list from folks who are trying to use JDBC and Tomcat together to link database information to the web. In my case I'm using PostgreSQL on Debian linux, but all of the concepts here should apply to just about any database access through the JDBC API on any platform.

If you are having problems with PostgreSQL JDBC that are unrelated to Tomcat, there is a FAQ for that also.

Tony Grant has put together a nice article on using PostgreSQL, Tomcat, Apache, and Macromedia UltraDev on RedHat Linux .This approach avoids having to deal with JDBC. This article should also be useful to those working on configuration of any of these tools.

The questions:

• I'm getting a ClassNotFoundException for the driver
• I'm getting a "broken pipe" error or a message that says only "java.lang.object".

If you get a runtime error that says "ClassNotFoundException", but had no problems compiling the servlet, it may be that the process running Tomcat doesn't have the JDBC jar in its class path. This is a sneaky problem, because everything seems to be fine until you start running servlets.

There are a couple of ways to solve this problem:

1. You can set the classpath in the ".profile" of the user that Tomcat runs as (usually www-data by default). This is a good approach if the user is not likely to change and you don't want to mess with any of the scripts that were installed with Tomcat. The downside to this approach is that some people like to run Tomcat in an interactive session during development so they can see messages as they happen- if you do this, you'll need to you do an su - to the right user before (re)starting Tomcat.
2. You can edit the shell file that starts up Tomcat to set the classpath. There is usually a file called /etc/init.d/tomcat. Just scan through this to the place where it adds the servlet classes to the classpath, and add the JDBC jar file at the same point. The downside to making the change here is that the next time you upgrade, this file may get over-written, so remember to check it after any Tomcat upgrade.

These error messages usually indicate that something has occurred that caused Tomcat to reload one or more of your classes. There are some problems with determining the dependencies between classes in Tomcat, so it is common for any open database connections or connection pools to get lost in the process. This results in messages indicating problems with a database object, but the cause was just an incomplete reload of classes.

The Tomcat development folks know about this problem & fixing it is on the list.

The way to solve the problem for now is to either restart Tomcat or reload the context. You can reload the context using the Admin utility that comes in the example applications with Tomcat (usually just <hostroot>/Admin). In version 3.2, this utility has a problem, but it works in other versions.)
Both of these actions will init the servlet that you use to load your connections.