4

Just whacking together an export from an old DB that contains binary data, I stumbled over an exception in one of our utility methods:

java.lang.AbstractMethodError: net.sourceforge.jtds.jdbc.BlobImpl.free()

After checking our codebase, I found that utility method was never used until now, bascially it looks like this:

public BinaryHolder getBinary(final int columnIndex) throws SQLException {
    Blob blob = null;
    try {
        blob = resultSet.getBlob(columnIndex);
        final BinaryHolder binary = BinaryHolderUtil.create(blob);
        return binary;
    } finally {
        if (blob != null)
            blob.free();
    }
}

BinaryHolder is just a wrapper that holdes the binary data (and before you ask, the code executes fine until it reaches the finally clause - BinaryHolderUtil.create(blob) does not attempt to free the blob).

Investigating further I found that everywhere else we access Blob's, the blob is just obtained using getBlob() and not free'd at all (The Javadoc says it will be automatically disposed of when the result set is closed).

Question now: Should the blob be free()'d manually (after all the ResultSet may be held for more than just accessing the blob), and if yes how can it be free()'d in a way that works even with a driver that does not implement it?

(We are using SQL-Server with JTDS1.25, if that wasn't already obvious from the exception)

Durandal
  • 19,919
  • 4
  • 36
  • 70

1 Answers1

7

The Blob.free() was introduced in JDBC 4.0 / Java 6. So you are most likely using a JDBC 3.0 or earlier JDBC driver.

As with most (JDBC) resources, closing them as soon as possible has its advantages (eg GC can collect it earlier, database resources are freed etc). That is also why you can close a ResultSet even though it is closed when you close the statement (or execute the statement again), just like you can close a Statement even though it is closed when the Connection is closed.

So a Blob does not need to be freed, but it is - in general - a good idea to free it when you are done with it.

BTW: JTDS is only JDBC 3.0, you would be better off using the Microsoft SQL Server JDBC driver of Microsoft itself.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
  • So if I want to keep the code generic *and* clean I have no other option than catching any exceptions that may be thrown from Blob.free()? I'm aware that JTDS implements only JDBC3, but the Microsoft driver has its own footcatches (I remember last years desaster with Java7 just too well). – Durandal Aug 06 '12 at 14:51
  • In this case you simply can't use `Blob.free()` as it isn't implemented in the driver; you are limited to JDBC 3.0 functionality (ie Java 1.4 / Java 5). – Mark Rotteveel Aug 06 '12 at 16:08
  • I have a concern, when I try to free up the blob thereafter I was unable to return the values. The execution ends and the byte value that I want to return is not returning. Why does this happen? – Niroshan Ratnayake Feb 28 '22 at 02:09
  • 1
    @NiroshanRatnayake That happens because you freed the blob. As [documented](https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/Blob.html#free()): _"The object is invalid once the free method is called. "_ You should only free a blob *after* you're done using it. – Mark Rotteveel Feb 28 '22 at 10:00