[
https://issues.apache.org/jira/browse/DERBY-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586590#action_12586590
]
Kathey Marsden commented on DERBY-3574:
---------------------------------------
Well the lobs are freed on the server with commit/rollback, just not marked
invalid on the client. So there is not a need for all of the work of free().
I hate to keep a list of lobs just for this. Part of me thinks the caching of
the length is not such a good idea. If we got rid of that, at least for
locators, we wouldn't have this problem.
Let me think about it some more and perhaps others will have better ideas in
the meanwhile.
Kathey
> 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.
