Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <32100713.1181716826209.JavaMail.jira@brutus>
Date: Tue, 12 Jun 2007 23:40:26 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.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.
In-Reply-To: <785582.1181051545961.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Knut Anders Hatlen commented on DERBY-2763:
-------------------------------------------

I'm not familiar with all the details in this discussion, but here are my two cents:

I think it would be perfectly fine if we said that when reading a stream returned by [BC]lob.get*Stream(), one may or may not see one's own updates made to that LOB after the call to get*Stream(). I guess a portable application couldn't rely on any particular behaviour anyway, and it would have to call get*Stream() after the update to get a fresh stream if it needed to see the updated value. If we define the behaviour this way, those applications that need the updated value pay the extra cost themselves, whereas those that don't care about this (that is, most applications) wouldn't have to pay for the extra complexity, emptying of buffers etc.

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