Notes on mapping of java.sql.Blob and java.sql.Clob interfaces

The usual Derby locking mechanisms (shared locks) prevent other transactions from updating or deleting the database item to which the java.sql.Blob or java.sql.Clob object is a pointer.

However, in some cases, Derby's instantaneous lock mechanisms could allow a period of time in which the column underlying the java.sql.Blob or java.sql.Clob is unprotected. A subsequent call to getBlob/getClob, or to a java.sql.Blob/java.sql.Clob method, could cause undefined behavior.

Furthermore, there is nothing to prevent the transaction that holds the java.sql.Blob/java.sql.Clob (as opposed to another transaction) from updating the underlying row. (The same problem exists with the getXXXStream methods.) Program applications to prevent updates to the underlying object while a java.sql.Blob/java.sql.Clob is open on it; failing to do this could result in undefined behavior.

Do not call more than one of the ResultSet getXXX methods on the same column if one of the methods is one of the following:
These methods share the same underlying stream; calling more than one of these methods on the same column could result in undefined behavior. For example: 
    ResultSet rs = s.executeQuery("SELECT text FROM CLOBS WHERE i = 1");
    while (rs.next()) {
        aclob = rs.getClob(1);
        ip = rs.getAsciiStream(1);
    }

The streams that handle long-columns are not thread safe. This means that if a user chooses to open multiple threads and access the stream from each thread, the resulting behavior is undefined.

Clobs are not locale-sensitive.

Parent topic: Mapping of java.sql.Blob and java.sql.Clob interfaces