db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2763) In the Network Client InputStream returned using Blob.getBinaryStream() should reflect the changes made to the underlying Blob.
Date Fri, 08 Jun 2007 05:51:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502677

V.Narayanan commented on DERBY-2763:

It seems to me that we have quite a few alternative behaviors:

1. Streams still see the old data.
2. Streams sees the changes that have been made to the part of the Lob
    that has not yet been read.
3. Streams throw an exception saying that it is invalid since Lob has
    been updated.
4. Change just maxPos and leave the rest as it is (incl. buffering)
5. Do nothing

The spec does not seem to say anything about this.

1. is not possible without very much work and overhead.
2. is some work, but will make it similar to embedded.
3. should not be much work, acceptable solution, but different from
    embedded.  However, it would not be much work to make embedded
    behave the same way.
4.-5. even less, need to say that behavior is unpredictable.

In case we pick 2., I think I prefer the same solution as Anurag has
done for embedded.  It introduces a few more classes, but it isolates
the mechanism needed here (separation of concerns), and it does not
reimplement mechanisms already provided by Java.  Getting buffering
right may also be a bit tricky, and if there already is a working
mechanism, I do not think we need to change that.

A similar situation exists for streams from Clobs(DERBY-2764 also).

> In the Network Client InputStream returned using Blob.getBinaryStream() should reflect
the changes made to the underlying Blob.
> -------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-2763
>                 URL: https://issues.apache.org/jira/browse/DERBY-2763
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions:
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For:
>         Attachments: LOBLengthPersists.java
> Currently the Embedded and Network Client would differ 
> in behaviour when the following series of steps is 
> followed.
> a) Create an empty Blob
> b) get an InputStream using Blob.getBinaryStream()
> c) write data into this Blob
>    c.1) Get an OutputStream
>    c.2) Use OutputStream.write(byte [] b) to write
>         into this Blob.
> d) Now read from the InputStream obtained in step b)
>    and print the number of bytes read as output.
> The output of step d) differs in the client and in the Embedded side.
> In the Client
> -------------
> The number of bytes read would always be -1.
> In the Embedded
> ---------------
> The number of bytes would be the number of bytes we
> reflected.
> The above behaviour in the NetworkClient is because
> the length of the Blob is read once and stored in the 
> constructor of the locator Stream returned (in the 
> attribute maxPos).
> This instead should be read each time we use the streams.
> A similar issue exists for Clobs also.
> I will raise a seperate JIRA issue for this.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message