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
