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