db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Created: (DERBY-3469) Clob.length() doesn't detect a closed underlying connection in a consistent way
Date Tue, 26 Feb 2008 10:09:51 GMT
Clob.length() doesn't detect a closed underlying connection in a consistent way

                 Key: DERBY-3469
                 URL: https://issues.apache.org/jira/browse/DERBY-3469
             Project: Derby
          Issue Type: Bug
          Components: JDBC, Network Client
    Affects Versions:,
         Environment: Client-driver
            Reporter: Kristian Waagan
            Priority: Minor

Depending on the state of the Clob, the method length gives two different SQL states when
the underlying connection has been closed.
According to BlobClob4BlobTest.testClobAfterConnectionClose, it should throw 08003 (no current
connection), but it might also throw XJ215 (invalid lob).

I think this is caused indirectly by the following method in Lob:
    long sqlLength() throws SqlException 
        if (lengthObtained_) return sqlLength_;
        if (isLocator()) {
            sqlLength_ = getLocatorLength();
            lengthObtained_ = true;
        } else if (willBeLayerBStreamed()) {
            throw new SqlException(agent_.logWriter_,
        } else {
            materializeStream();  // Will set sqlLength_

        return sqlLength_;

In this method, getLocatorLength will check for a closed connection (somewhere down in prepareCallX
i believe), whereas the cached length is returned if it has already been determined. Clob.length
does not check for a closed connection.
There are multiple fixes, but I think a proper investigation should be carried out before
a solution is chosen. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message