What I discovered was that there were a large number of SybSQLWarning and SybSQLResultSet objects hanging off of the cached PreparedStatement objects that my JDBC connection manager was using. I found that the SybSQLWarning objects were all chained together, one after another, and that each had a reference to the SybSQLResultSet that it came from.

After adding a call Statement.clearWarnings() in the leg of code that reuses PreparedStatements, the stray objects went away. Great I said!

Well, I didn't really think that I should need to call Statement.clearWarnings(), and so I did some more looking around on the internet and found the link:

    http://java.sun.com/developer/onlineTraining/Database/JDBC20Intro/JDBC20.html

SQL Warnings

An SQLWarning is a subclass of SQLException, but is not thrown like other exceptions. The programmer must specifically ask for warnings. Connections, Statements, and ResultSets all have a getWarnings() method that allows retrieval. There is also a clearWarnings() method to avoid duplicate retrievals. The SQLWarning class itself only adds the methods getNextWarning() and setNextWarning().

An SQLWarning is very similar to traditional compiler warnings: something not exactly right occurred, but its effect was not severe enough to end processing. Whether it is important enough to investigate depends on the operation and context. An example of an SQLWarning is mentioned in the Scrollable Result Sets section.

Statements clear warnings automatically on the next execution. ResultSets clear warnings every time a new row is accessed. The API documentation is silent regarding Connection; to be cautious, issue clearWarnings() after warnings are obtained.