db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (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 Tue, 12 Jun 2007 18:48:26 GMT

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

Rick Hillegas commented on DERBY-2763:
--------------------------------------

The regressiion tests pass cleanly for me after applying this patch. I have some additional
comments:

General:

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?

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.

UpdateSensitiveLOBLocatorInputStream

3) I think this class should be abstract. Methods to be implemented by subclasses should be
abstract too.

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.


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?

> 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