db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anurag Shekhar (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 05:46:26 GMT

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

Anurag Shekhar commented on DERBY-2763:

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

I think you are talking about the case where a write is in progress 
and at the same read is called and read gets partially updated data. 
This particular scenario is taken care by LOBStreamControl please 
note this class is central repository of all lob classes (for both 
network client and embedded driver). LOBStreamControl 
synchronizes all read and write methods so a read will never
pickup data which is still being written. 

But I do agree there may be another race condition when there 
is a modification after checking for obsoleteness and before read.
But I am not sure we really need to handle this case as in this 
case data will be same if the reader thread was scheduled before 
the writer thread.

> 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:
>            Reporter: V.Narayanan
>            Assignee: V.Narayanan
>             Fix For:
>         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,
> 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.

View raw message