db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-721) State of InputStream retrieved from resultset is not clean , if there exists previous InputStream .
Date Mon, 05 Dec 2005 23:24:37 GMT

Is there anything in the standard that says what the second call to
the get the stream has to do?  Imagine the case where the first
stream reads 1 gig of a 2 gig blob, does the second call to 
getBinaryStream() have to return the 1st gig again?

Any change that tries to cache the bytes returned by the first
getBinaryStream either in local client or network client code is
going to be a performance/memory drain.

/mikem

Daniel John Debrunner wrote:
> Mike Matrigali wrote:
> 
>>I am new to this issue and have not reviewed the patch yet.  I am just
>>trying to understand what the correct behavior is.  If this has
>>already been discussed feel free to point that out.I know Sunitha
>>submitted some fixes in this area, but she will not be able to look
>>at these for awhile.
>>
>>In your test it is obvious that the first instance of the stream can
>>not be used anymore since you use the same variable.  What if the
>>test instead did:
>>
>>InputStream is1 = rs.getBinaryStream(1);
>>System.out.println("Here goes first stream");
>>System.out.println(is1.read());
>>System.out.println(is1.read());
>>System.out.println(is1.read());
>>    
>>InputStream is2 = rs.getBinaryStream(1);
>>System.out.println("Here goes 2nd stream");
>>System.out.println(is2.read());
>>System.out.println(is2.read());
>>System.out.println(is2.read());
>>
>>System.out.println("Here goes first stream continuing");
>>System.out.println(is1.read());
>>System.out.println(is1.read());
>>System.out.println(is1.read());
> 
> 
> The second call to getBinaryStream is required to close the first stream.
> 
> Dan.
> 
> 
> 


Mime
View raw message