Bryan Pendleton wrote:
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.
This sounds like a very similar situation but in the case of DERBY-3085
it is the server that is not consuming the entire stream.
- The client has prepared a statement to update a row with a parameter
marker.
- The client uses setBinaryStream to set the parameter.
- The server executes the statement but finds no rows to update, so does
not consume the stream.
- The remnants of the parameter data are left in the network server stream.
One thing I noticed is that the streaming of parameter data only happens
for the last parameter with EXTDTA. That is why it works with multiple
parameters when there is a row to update.
There is this code from DRDAConnThread.readAndSetAllExtParams()
final boolean doStreamLOB = (streamLOB && i == numExt -1);
readAndSetExtParam(paramPos,
stmt,
stmt.getParamDRDAType(paramPos+1),
stmt.getParamLen(paramPos+1),
doStreamLOB);
