O mecanismo normal de bloqueio do (bloqueios compartilhados) impede que outras transações atualizem ou excluam um item do banco de dados para o qual o objeto java.sql.Blob ou java.sql.Clob seja um ponteiro. Entretanto, em alguns casos, o mecanismo de bloqueio instantâneo do pode admitir um período de tempo onde a coluna subjacente a java.sql.Blob ou java.sql.Clob fique desprotegida. Uma chamada subseqüente ao método getBlob/getClob, ou java.sql.Blob/java.sql.Clob, pode causar um comportamento indefinido.

Além disso, não há nada que impeça a transação que mantém java.sql.Blob/java.sql.Clob (ao contrário das outras transações) atualizar a linha subjacente (O mesmo problema existe com os métodos getXXXStream). Os aplicativos devem ser programados para impedir atualizações no objeto subjacente, enquanto houver um java.sql.Blob/java.sql.Clob aberto para o objeto; se isto não for feito, pode resultar em um comportamento indefinido.

Não deve ser chamado mais de um método getXXX de ResultSet para a mesma coluna, se um dos métodos for um dos seguintes:

• getBlob
• getClob
• getAsciiStream
• getBinaryStream
• getUnicodeStream

Estes métodos compartilham o mesmo fluxo subjacente; chamar mais de um destes métodos para a mesma coluna pode resultar em um comportamento indefinido. Por exemplo: ResultSet rs = s.executeQuery("SELECT text FROM CLOBS WHERE i = 1"); while (rs.next()) { aclob=rs.getClob(1); ip = rs.getAsciiStream(1); }

Os fluxos que tratam colunas longas não são seguros quanto a thread. Isto significa que se for decidido abrir várias threads, e acessar o fluxo a partir de cada uma das threads, o comportamento resultante será indefinido.

OS Clobs não são afetados pelo idioma.