db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: [jira] Commented: (DERBY-3085) Fails to handle BLOB fields with a PreparedStatement with size >32750 bytes
Date Thu, 27 Sep 2007 02:16:45 GMT
>> I vaguely recall discussions of
>> such an algorithm during the LOB locator development, so there may
>> in fact be such code in the client, but it's not working for some
>> reason or another.
> 
> Thank you Bryan for looking at this.  Is the LOB locator development 
> relevant to parameters being sent from the client or only LOBs being 
> returned from the server?

Hi Kathey,

I did some searching through JIRA and the mailing list, but failed to
quickly find the discussion that I remembered.

It's quite possible that I was remembering a discussion that occurred
during the Layer B Streaming project, and that work has I think now
been supplanted by the locators implementation, so it may no longer
be relevant.

Still, I think it went something like this:

  - The client has called ResultSet.next(), and has positioned itself
    to a row containing one or more lobs.
  - The client has fetched some of the column data, but has not fully
    retrieved all of the data of (at least one of) the LOBs.
  - The client then calls next() again to move off of this row and
    on to the next row.

At this point, there was a time during development where Derby did not
handle this properly, and then some code was put in place to detect
this situation and fully read any un-read LOB data from the row that
we're moving away from, prior to setting up for the next row.

I'll keep trying to track down the details, but hopefully this memory
is helpful and stimulates somebody else's memory of this situation.

thanks,

bryan


Mime
View raw message