db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (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 15:37:26 GMT

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

Rick Hillegas commented on DERBY-2763:
--------------------------------------

Hi Narayanan,

Thanks for the crisp descrition of the possible solutions. I have a couple immediate reactions:

A) It would be good if the embedded and network behavior agreed.

B) I don't  understand what it means to read out of a blob with one hand while you are writing
into it with the other.

It's worth pointing out that the same issues arise if you are writing to the Blob using Blob.setBytes()
at the same time as you are siphoning out bytes using the InputStream returned by Blob.getBinaryStream().


Issue (B) troubles me. What does it mean to read the InputStream up to position X, then insert
a block of bytes which straddle that position (i.e., from X-A to X+B)? Quite likely, the inserted
bytes have some meaning as a complete block. What does it mean to read only the trailing portion
of that block?

My gut feeling is that we should raise an exception if someone tries to write into a Blob
which still has an open InputStream on it. I think this should be the behavior for both the
embedded and network clients.

Do we have real customer demand for some use-case supported by the current embedded behavior?
If not, I would recommend raising an exception now. We can relax this in the future if there's
real demand for a real use-case.

> 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: 10.3.0.0
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For: 10.3.0.0
>
>         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.


Mime
View raw message