# Notas

O mecanismo normal de bloqueio do Derby (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 Derby 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.

Tópico pai: java.sql.Blob e java.sql.Clob