[ http://issues.apache.org/jira/browse/DERBY-1471?page=comments#action_12419135 ]
Kristian Waagan commented on DERBY-1471: ---------------------------------------- Hello Tomohito, I think your plan makes sense, where we go for option 1. This way, DERBY-1417 (lengthless overloads) can move forward without waiting for DERBY-1471 (layer B streaming). I think I will go for for a very simple solution for the overloads on the client side, unless someone has better ideas. The approach is to exhaust the application stream and copy it into memory to determine the length. If the data is too big to fit in memory, the client will fail with an out-of-memory exception. The only alternative I can think of, is to "temporarily" store data on disk on the client to avoid memory problems, but I think this is a bad idea... There is also another existing issue on the client, where large LOBs cause out-of-memory exception even when the length is specified (is it DERBY-1472?). We can improve/reevaluate the lengthless overloads when DERBY-1471 has reached completion. Regards, > Implement layer B streaming for new methods defined in JDBC4.0 > -------------------------------------------------------------- > > Key: DERBY-1471 > URL: http://issues.apache.org/jira/browse/DERBY-1471 > Project: Derby > Type: New Feature > Components: Network Client > Reporter: Tomohito Nakayama > Assignee: Tomohito Nakayama > > JDBC 4.0 introduced new methods which take parameters for object to be sent > to sever without length information. > For those methods, Layer B streaming is best way to implement sending object > to server. > This issue is representation of DERBY-1417 in Network Client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
