[
https://issues.apache.org/jira/browse/DERBY-3781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613852#action_12613852
]
Kristian Waagan commented on DERBY-3781:
----------------------------------------
Regarding the convenience link, using this.resetStream() instead of
resettable.resetStream() wouldn't fix the problem. It would only cause another
inconsistent state.
The problem is that the stream skipping and the position update isn't "atomic"
in the case of requesting a position after EOF. The code simply wasn't properly
written for handling this failure scenario.
The convenience link isn't required, and only used in a few places, so removing
it sounds like an improvement. I'll make a patch after 1a has been committed.
> 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
> Attachments: derby-3781-1a-fix_and_test.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.
