JDBC 4.0’s Lesser-known Clob.free() and Blob.free() Methods

When I talk about jOOQ at conferences, I always show this slide containing a bunch of very common JDBC mistakes that people often commit:

Six common JDBC bugs in this image
Six common JDBC bugs in this image

Can you find the bugs? Some of them are obvious, such as:

  • Line 4: Syntax errors resulting from bad concatenation on line 3
  • Line 7: Syntax errors and SQL injection risk due to variable inlining
  • Line 8: Wrong bind index resulting from a potential mismatch on line 3
  • Line 14: Wrong column name due to sloppy rename
  • Line 18: Bad resource management

But then, there’s another very subtle bug that most people are unaware of because the fix was only possible since the upgrade in Java 6 / JDBC 4.0. See the solution, below:

Solution to the previous six bugs
Solution to the previous six bugs

With JDBC 4.0, the Clob.free() and the Blob.free() methods were introduced. While calling them is optional, it may be a very bad idea not to call them as early as possible, as you should not rely on the garbage collector to kick in early enough to free these resources. In fact, in certain databases / JDBC drivers, LOBs can outlive individual statements and/or transactions. They’re beasts of their own. If you’re reading through the JDBC tutorial (and also in the JDBC specification), it says:

Blob, Clob, and NClob Java objects remain valid for at least the duration of the transaction in which they are created. This could potentially result in an application running out of resources during a long running transaction.

The same is true for arrays, which also have an Array.free() method since Java 6 / JDBC 4.0.

So if your application has long-running transactions, do call these free() methods, or make it a habit to always call them. We’ll file an issue to FindBugs to make this a potential bug pattern.

6 thoughts on “JDBC 4.0’s Lesser-known Clob.free() and Blob.free() Methods

  1. your bug-fix-solution is questionable – the code should be rewritten. There is absolutely no excuse for that silly ‘isAccount-orgy’.
    If i would see such code in the wild i would throw some Celko-books at the programmer….

    1. Yes, Celko-books, Karwin-books and many more :-)
      Obviously, none of the bug-fix-solutions here are long-lasting. These are just examples of bad code encountered in the wild. People tend to learn from bad code…

  2. A better question is why Blob/Clob do not implement AutoCloseable. If they were, it would be a lot easier to clean up after them.

    1. Good point. Well, AutoCloseable was introduced in Java 7. These free() methods in Java 6. Obviously, one might wonder why they didn’t call the methods close() in the first place.

      1. At this point they can:

        1. Implement AutoCloseable
        2. Add close()
        3. Have free() delegate to close()
        4. Deprecate free().

        Done :)

Leave a Reply