[
https://issues.apache.org/jira/browse/DERBY-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503939
]
Rick Hillegas commented on DERBY-2763:
--------------------------------------
Thanks for the quick response, Narayanan. I think I can see how this patch
reduces the possibility of the inconsistency which you describe. However, I
think that there are race conditions in this patch which could still give rise
to that inconsistency--because the read() methods handshake with the writers on
entry and not on exit.
Inconsistencies of some sort can always arise if the contents of the LOB change
between the time that reading starts and the time that reading ends. I think
that's true with or without this patch. This patch may change the kind of
inconsistencies that can occur and this patch may reduce the possibility of
certain inconsistencies. Whether those inconsistencies are acceptable depends
on what the application is doing and what it expects.
What I'm struggling to understand is this: why are the inconsistencies allowed
by this patch better than the inconsistencies allowed if we don't do anything?
What are the supported use-cases which we want to document? If I understood
those use-cases, then I could reason about whether this patch actually delivers
the intended benefit.
Thanks!
> In the Network Client InputStreams and Readers returned from LOB's should be
> sensitive to underlying LOB data changes.
> ----------------------------------------------------------------------------------------------------------------------
>
> 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: Approach_2.diff, Approach_2.stat, Approach_2.txt,
> Approach_3.diff, Approach_3.stat, Approach_4.diff, Approach_4.stat,
> LOBLengthPersists.java, UpdateSensitiveStreamsForClient_v1.diff,
> UpdateSensitiveStreamsForClient_v1.stat
>
>
> 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.
