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
