db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2992) getBinaryStream returns incorrect result (truncated value) if underlying blob is deleted
Date Wed, 10 Feb 2010 14:24:28 GMT

    [ 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:,,,,
>            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.

View raw message