[
https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613876#action_12613876
]
Knut Anders Hatlen commented on DERBY-3781:
-------------------------------------------
2a looks good. Perhaps it would be better to use ASSERT instead of
IllegalArgumentException? Then we don't need to worry about the risk of
presenting non-localized error messages to the users, or about increasing the
footprint of the production jars. The error won't be hidden in production code,
it'll just happen another place, and I think it'll still be fairly easy to see
what the problem is from the ClassCastException that will be presented.
Another thing I came to think about - is it possible to expose the original
problem through JDBC? If it is, then it might be valuable to add a regression
test that uses JDBC in addition to the one that accesses the
PositionedStoredStream class directly.
> PositionedStoreStream.reposition(pos) with pos greater than length leaves the
> stream object in an inconsistent state
> --------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3781
> URL: https://issues.apache.org/jira/browse/DERBY-3781
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.5.0.0
>
> Attachments: derby-3781-1a-fix_and_test.diff,
> derby-3781-2a-remove_convenience_link.diff
>
>
> PositionedStoreStream.reposition(pos) with pos greater than the stream length
> leaves the stream object in an inconsistent state, causing subsequent calls
> to fail or the state to remain inconsistent (which can cause the wrong data
> to be returned).
> The problem is that the position variable gets out of sync with the
> underlying stream.
> There are at least two ways to fix this (assuming the positioned store stream
> does not know the length of the underlying stream):
> a) Reset stream to position zero.
> b) Let the stream be positioned at EOF and update the internal position
> variable.
> Option b) leaves the stream in an unusable state, and the next request will
> cause option a) to be performed. It also require a slight rewrite of
> 'PositionedStoreStream.skipFully' and 'PositionedStoreStream.reposition' to
> be able to determine the position of the stream (the length in this case).
> Option a) will cause the first page of the stream to be read into the cache
> (if not already there), but taken the reason for doing this is an error
> condition it seems acceptable.
> A correct value of the position variable is required for correct/valid
> operation of PositionedStoreStream.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
