db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (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 Mon, 11 Jun 2007 09:24:26 GMT

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

Øystein Grøvlen commented on DERBY-2763:

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

I agree.  I think that is more important than the actual behavior

> 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?

A Blob or Clob may well be structured data where segments may be
updated independently.  Hence, it may make sense to read and update
Lobs a segment at a time.  However, I agree that it is not very likely
that one update in the middle of where one is reading.

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

On use-case I can think of: Read first segment, make update to that,
continue to read second segment, and so on.  This will not be possible
if we raise an exception as you suggest.  (You can get around it
around this by closing the stream and creating a new one, but you will
then get the overhead of repositioning.)  In this use-case, it does
not matter whether one is able to see one's own updates or not, since
one will never be reading segments that have been updated. Hence, any
behavior, except raising an exception, would support this use-case. I
think the advantage of the way Anurag has implemented it on the
embedded is that it is a well defined behavior that is easy to explain
to users.  I think a clean behavior is to be preferred over an
unpredictable behavior if it does not require much extra work.

I agree that it is better to make a strict behavior now and relax it
later if needed, than risking to have to restrict the behavior in
later versions.  I guess the main risk is that future JDBC specs would
require a specific behavior.  However, it is likely that different
vendors have different behavior today and that the only thing they
will agree on is to say that the behavior is unpredictable.

> 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: Approach_2.diff, Approach_2.stat, Approach_2.txt, Approach_3.diff,
Approach_3.stat, Approach_4.diff, Approach_4.stat, 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