[
https://issues.apache.org/jira/browse/DERBY-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586179#action_12586179
]
Kathey Marsden commented on DERBY-3574:
---------------------------------------
I spoke with Tiago on IRC about this and we came to the conclusion that.
1) There would be a problem with the patch if a transaction was committed and
then another one began.
2) The error message should be localized.
3) It would be nice if checkValidity() could do this check but we don't mark
client Lobs as invalid on commit()/rollback().
4) Length is a problem and not getSubString() etc because we cache the result
of length(). I wonder with updatable resultSets if it is even valid to cache
this result.
> 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
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3574
> URL: https://issues.apache.org/jira/browse/DERBY-3574
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client, Newcomer
> Affects Versions: 10.5.0.0
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Priority: Trivial
> Attachments: derby-3574.patch, TestLobLength.java
>
>
> Attempting to get call Blob/Clob.length() after commit or connection close
> does not fail if there was a previous call to length(). If no previous call
> was made an exception is thrown as expected.
> See attached program TestLobLength for repro with commit. If you comment out
> the two lines to get the length before the commit we get the expected
> exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.