I don't have enough information to completely answer, but will try to state my opinion on the issue.
I think the goals should be: 1) provide same behavior in embedded and network server mode. 2) provide same behavior whether the blob is "small" or "large". 3) optimize the standard case of getting the column once in jdbc, as the spec allows. 4) If at all possible when selecting a blob/clob as a stream it should not be necessary to materialize the entire stream in memory. For embedded I was worried about your description of changes, that made it sound like you somehow were going to buffer the blob in memory. I see from your changes you basically added reset calls if the underlying stream was resetable. What I don't know is what happens in the 2 gig blob/clob cases, either you will have to investigate or maybe someone on the list knows? For embedded it is theoretically possible for the reset of the stream to go all the way back to store and read it again from the beginning. For network client this seems even more complicated to do in an optimized way (I believe you are looking at improving the streaming behavior of large objects to network client so I defer to you in how hard this may be). My opinion would be to make the second reference throw an error, to make that behavior consistent in network server, embedded, long and short blob/clob streams. And to document that behavior. Having said that, I am not against the code working as you are moving toward as long as it does not cause a memory/runtime performance issue for the normal single get stream case. TomohitoNakayama wrote: > 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. >> >> >> >> >> >> >
