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.Clobmethod, 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.
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.