db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2763) In the Network Client InputStreams and Readers returned from LOB's should be sensitive to underlying LOB data changes.
Date Wed, 13 Jun 2007 06:56:26 GMT

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


Mime
View raw message