db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (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 10:27:26 GMT

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

Øystein Grøvlen commented on DERBY-2763:

Rick Hillegas (JIRA) wrote:
> Thanks for the patch, Narayanan. I am reading it now. Here is an initial reaction:
> It seems to me that the input stream's position is an offset from
> the start of the LOB. When the stream is recreated, the current
> position (offset from the start of the LOB) does not change. So it
> seems to me that Øystein's use-case is supported if the rewritten
> chunks do not change size. So, I am puzzled. To support that use
> case, is there any need to recreate the streams? It appears to me
> that the recreation of the streams supports some other use-case, in
> which the writer is writing bytes further on in the LOB, and not in
> the porition that has already been read.

The use-case I came up with, is an argument for not throwing an
exception when the underlying LOB has been changed since the stream
was created.  It does no require any particular behavior with respect
to whether the updates will be seen by the stream.

My arguments for choosing the implementation that Narayanan proposes is:

  - This is the way it has been implemented in the embedded driver
  - It gives a clean behavior that is very easy to explain and
    understand: You will see all updates made so far.

An alternative is, as Knut Anders suggests, that we give no guarantees
with respect to what updates will be seen.  The given use-case will
still be supported.  I guess we can make that the official story also
for embedded driver, even if the implementation guarantees a specific

> Do we have a use-case in mind for this scenario? It would be nice to
> be able to argue to ourselves that we are building something that
> solves a customer problem here.

I doubt that most users would care here.  It seems to me that if you
need to work with a LOB, and need to read something you have written
earlier, an application could use other data structures that are more
suitable than Blob/Clob objects (e.g., a byte array or a local file).
Also, if you insists on using Blob/Clob objects for this purpose, you
will be able to see your updates if you open a new stream.

(Maybe a bit far-fetched, but Blob/Clob objects give you a mechanism
for temporary storage of large objects on a server.  It will probably
be more efficient than storing them in a database table since the
temporary LOBs support direct access to specific positions within the
LOB, something Store does not.)

> 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