[
https://issues.apache.org/jira/browse/DERBY-2992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832003#action_12832003
]
Kristian Waagan commented on DERBY-2992:
----------------------------------------
Thanks for looking at the patch, Knut Anders.
Your proposed message sound better to me, and I think it doesn't lie :) That
is, I believe there aren't any other valid reasons causing that exception to be
thrown. If you use a stricter isolation level I think locks will be put in
place to avoid that a different transaction deletes the value you are currently
accessing.
The only other reason I can think of, is if we have a bug in the store
specifying the wrong overflow page id.
I'll change the error message and commit the patch shortly.
> getBinaryStream returns incorrect result (truncated value) if underlying blob
> is deleted
> ----------------------------------------------------------------------------------------
>
> Key: DERBY-2992
> URL: https://issues.apache.org/jira/browse/DERBY-2992
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.2.2.0, 10.3.1.4, 10.4.1.3, 10.5.3.0, 10.6.0.0
> Reporter: Kathey Marsden
> Attachments: derby-2992-1a-throw_exception_on_eof.diff,
> TruncatedBlob.java
>
>
> If getBinaryStream is reading a value (READ_UNCOMMITTED) and the row is
> deleted by another connection, a truncated value will be returned without
> error. I believe instead either the whole value or an IOException should
> occur.
> With 10.2 and higher with the repro attahed we get:
> > java TruncatedBlob
> Embedded:
> Read 32669 bytes
> 0 rows in BLOBCLOB
> With 10.1
> Embedded:
> Read 40000 bytes (OK)
> 0 rows in BLOBCLOB
> Note network server returns the full value for both 10.1 and 10.2 but gives a
> lock timeout for 10.2+. I will file a separate issue for that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
