[DERBY-3469] Clob.length() doesn't detect a closed underlying connection in a consistent way

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 10.3.2.1, 10.4.1.3, 10.5.1.1
• Fix Version/s: 10.4.2.0, 10.5.1.1
• Component/s: JDBC, Network Client
• Environment: Client-driver
• Assignee: Tiago R. Espinha
• Reporter: Kristian Waagan
• Created: 26/Feb/08 10:07
• Updated: 04/May/09 18:22
• Resolved: 26/May/08 13:37

Description

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_, LOB_OBJECT_LENGTH_UNKNOWN_YET); }

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.

Issue Links

• relates to: DERBY-3574 With client, attempting to get the lob length after commit or connection close if there was a call to length() before commit does not throw an exception