Debugging

Previous: Testing

Logging

Debugging Hibernate applications can be tricky because there's just so much going on inside of Hibernate. One of the best ways to get some idea is to enable Hibernate logging. However, it helps to do this selectively, otherwise you can be swamped with information.

For example, you probably know that setting the property hibernate.show_sql=true will cause Hibernate to write out the SQL that it generates (for more information, see here). However, this won't tell you what values it is binding to parameters in the SQL it generates. If you're using log4j, you can accomplish this by adding the line log4j.logger.org.hibernate.type=debug to your log4j.properties. For more information on what can be logged with Hibernate, see here.

Connection Leaks

A common problem that we have had is database connection leaks. From a Hibernate perspective, this is usually caused by opening a session and then not closing it.

We stumbled across an easy way to find the source of such leaks: the DBCP connection pool. Tomcat comes with DBCP built in , but you can also use it on it's own (although we haven't actually tried this).

DBCP provides a means of cleaning-up abandoned connections via the removeAbandoned and logAbandoned parameters. This can help stop connection leaks from causing you problems, but it doesn't address the underlying cause.

To find the code that is leaking the connection, you also need to activate DBCPs logAbandoned parameter. This causes DBCP to record a stack trace whenever it hands out a connection. If a connection is later abandoned and removed, DBCP will print out this stack trace. Examination of the trace will then reveal what code requested the connection in the first place. You can then examine the code to figure out why it's not releasing the connection.

Next: Tools