db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TomohitoNakayama <tomon...@basil.ocn.ne.jp>
Subject Re: [jira] Updated: (DERBY-721) State of InputStream retrieved from resultset is not clean , if there exists previous InputStream .
Date Tue, 06 Dec 2005 10:35:59 GMT
Hello Daniel and Mike .

Do you think it is preferable not to allow user to call getXXXXStream 
twice from one row ,
in order to make a room for releasing memory for cache in ResultSet as 
soon as possible ?

Best regards.


Daniel John Debrunner wrote:

>Mike Matrigali wrote:
>
>  
>
>>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?
>>    
>>
>
>Yes & no.
>
>Nothing in the JDBC spec doc, but the javadoc for java.sql.ResultSet has
>always had:
>
>" For maximum portability, result set columns within each row should be
>read in left-to-right order, and each column should be read only once."
>
>Thus, Derby could thrown an exception if there was a second getXXXStream
>call on the same column.
>
>  
>
>>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.
>>    
>>
>
>Agreed, we need to be careful here, we need to optmise the frequent
>case, getting the column's value once as-per JDBC.
>
>Dan.
>
>
>
>
>  
>

-- 
/*

        Tomohito Nakayama
        tomonaka@basil.ocn.ne.jp
        tomohito@rose.zero.ad.jp
        tmnk@apache.org

        Naka
        http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/ 


Mime
View raw message