[
https://issues.apache.org/jira/browse/DERBY-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504141
]
V.Narayanan commented on DERBY-2763:
------------------------------------
Thank you for the reviews, comments and the test Runs Rick.
>1) As noted earlier, there are race conditions in the read() methods
> because they check the update count on the way in and the LOB
> contents could change before the read() methods exit. Is this OK?
I read the comments from Anurag just now...
A small addition to that.
Writes and reads to LOB's are basically stored procedure calls with
the locator information passed as parameter. So during the case
pointed out when a read and a write simultaneously happen the calls
would be propogated un-affected by the presence of each other till
the LOBStreamControl class which then synchronizes the calls. So this
issue would be avoided here.
>2) I think that calling sqlLength() in order to check for committed
>transactions
> is a little tricky. I think it would be better if Lob exposed a method,
> say isValid() which has the required semantics. Under the covers,
> Lob.isValid() can call sqlLength() for the time being.
I initially thought of adding this in the checkValidity()
method of am/Blob and am/Clob. I then decided against this
because these methods were being called in the methods that
result in a Stored Procedure call themselves. For example
checkValidity is called in readBytes. If the locator associated
with this is valid then it will result in 2 round trips to the
server instead of two. One for the SqlLength() call and the
other for the BLOBSETBYTES stored procedure call. The initial
round-trip would not be necessary for this method since during
the call to BLOBSETBYTES itself we would find out that the
locator in invalid.
But your solution of keeping the locator valid check in one
place (Lob) is correct because if in the future we decide to
not use this we can change it at this place alone.
I will do this in the follow-up
UpdateSensitiveLOBLocatorInputStream
> 3) I think this class should be abstract. Methods to be implemented by
> subclasses
should be abstract too.
I agree. I found this while doing the mock review runs I do on my patches
to find silly mistakes. I am sorry, I missed implementing this. I will do
this in a follow-up.
> 4) Here is an issue for the documentation noted in my earlier comment today:
> Øystein's use case is
> supported only if a rewritten chunk is exactly the same length as the
> chunk it is replacing.
I guess the release note needed flag needs to be enabled and a
release note written. Will Do!
>BlobLocatorOutputStream
>ClobLocatorWriter
>ClobLocatorOutputStream
>5) Why is incrementUpdateCount() called in these streams? Shouldn't the update
>count be
> incremented by the Blob and Clob methods which do the actual writing?
readCharacters, writeCharacters, writeBytes on the Locator streams forward
their calls to
the framework that calls the stored procedures with the locator value
obtained
from the Lob. The only way to reach the update count being the Lob reference
that is maintained within these streams.
So when a user takes a OutputStream from a Lob and does not write
into it the InputStreams can continue reading un-hindered. When a
write into the OutputStreams or the Writer happens then we need to
do increment the updateCount.
Hence I decided to increment the updateCount by calling the
incrementUpdateCount
method using Lob reference mainted in the streams.
> 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.
