|
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.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.
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:
- getBlob
- getClob
- getAsciiStream
- getBinaryStream
- getCharacterStream
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.
|
