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.

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:

    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.

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

Talk Back!

Have an opinion? Readers have already posted 3 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.