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

["V.Narayanan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586387#action_12586387 ] 

V.Narayanan commented on DERBY-3469:
------------------------------------

This issue will have unexpected ramifications for the update sensitive Clob and Blob streams.

The update sensitive streams upon creation depend on the sqlLength() method to determine the
validity of the underlying Lob. If the sqlLength method returns the cached length value these
streams will not fail upon creation (getBinaryStream() and other methods) but when a read or
write is called upon them. I think they should uniformly fail when getBinaryStream() is called.

A easy way I can think of resolving this problem is to reset the "lengthObtained_" boolean, when
free(). This would ensure that the cached value is not used after a free is called.

I would design this by introducing a free() method in Lob and setting lengthObtained_=false in that
method and do a super.free() in the free methods of am/Clob and am/Blob.

I have not tested this solution yet, but it seems OK to me at first look.

> 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: 10.3.2.1, 10.4.0.0
>         Environment: Client-driver
>            Reporter: Kristian Waagan
>            Priority: Minor
>         Attachments: ClosedClobTest.java
>
>
> 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. 

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