db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From V.Naraya...@Sun.COM
Subject [JDBC] [LOB] Behavior of Streams returned from LOB (Related to DERBY-2763 and 2764)
Date Fri, 08 Jun 2007 06:05:08 GMT
Hi,

The following is a list of the possible solutions for  DERBY-2763 and DERBY-2764. I have
already commented the below list of points on DERBY-2763. But thought it would be better
to send it as an email also.

DERBY-2763 - In the Network Client InputStream returned using Blob.getBinaryStream() 
             should reflect the changes made to the underlying Blob.

DERBY-2764 -  In the Network Client Streams returned using Clob.getAsciiStream() and 
              Clob.getCharacterStream() should reflect the changes made to the 
              underlying Clob.

It seems to me that we have quite a few alternative behaviors:

1. Streams still see the old data.
2. Streams sees the changes that have been made to the part of the Lob
    that has not yet been read.
3. Streams throw an exception saying that it is invalid since Lob has
    been updated.
4. Change just maxPos and leave the rest as it is (incl. buffering)
5. Do nothing

The spec does not seem to say anything about this.

1. is not possible without very much work and overhead.
2. is some work, but will make it similar to embedded.
3. should not be much work, acceptable solution, but different from
    embedded.  However, it would not be much work to make embedded
    behave the same way.
4.-5. even less, need to say that behavior is unpredictable.

In case we pick 2., I think I prefer the same solution as Anurag has
done for embedded.  It introduces a few more classes, but it isolates
the mechanism needed here (separation of concerns), and it does not
reimplement mechanisms already provided by Java.  Getting buffering
right may also be a bit tricky, and if there already is a working
mechanism, I do not think we need to change that.

Narayanan


Mime
View raw message