Question

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)

Answer 1

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.