Summary
Sybase's implementation of PreparedStatement does not use Statement.clearWarnings() automatically on repeated uses. This results in the accumulation of SybSQLWarning and SybSQLResultSet objects, one pair per call use.

Advertisement

I've been using the Your-Kit Java Profiler on one of my customer's systems to identify the source of an OutOfMemoryError and occasional SIGSEGV or SIGBUS termination that seemed to happen intermitently.

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:

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.

This seems like an implementation shortcomming. Has anyone else been bit by this Sybase "feature"?