[ http://issues.apache.org/jira/browse/DERBY-1292?page=comments#action_12378225 ]
Bryan Pendleton commented on DERBY-1292: ---------------------------------------- I think there is a design issue here with respect to the PreparedStatement data structures, and the handling of batch operations. PreparedStatement.java records information about the types of the various columns in the statement using a ColumnMetadata object named parameterMetaData_: public ColumnMetaData parameterMetaData_; // type information for input sqlda But in the batch statement scenario, each batch element can have a different set of data type information. For example, in the reproduction program provided by Gerald Khin, the first batch element has the type information (column1:Varchar, column2: String), while the second batch element has the type information (column1:String, column2:Clob). The PreparedStatement appears to have a "last element wins" result here: each set of stmt.setString/stmt.setNull/stmt.setObject/etc. calls resets the values in the parameterMetaData_ object, so that when we reach the executeBatch call, the values in the parameterMetaData_ object record the types of the *last* batch element. But then the executeBatch call proceeds to use those types to interpret the data, starting with the *first* batch element. In the case of the repro script, this causes us to try to interpret the string "clob" as a Clob. If you change the repro program by replacing the Types.CLOB call in the second batch element with Types.INTEGER, then you get a different ClassCastException elsewhere in the client code, as the code tries to interpret the string "clob" as an Integer. I suspect that, in the batch execution case, the client code cannot use just a single parameterMetaData_ member in the PreparedStatement object, but rather needs to have a collection of ColumnMetaData instances, one for each batch element, and the addBatch() operation needs to add a ColumnMetaData instance to the collection, rather than simply re-using the same parameterMetaData_ instance. For the meantime, the workaround is to use the same type signatures in each batch element. For example, the program will work, correctly, if Types.CLOB in the second batch element is replaced by Types.VARCHAR. As long as you use the same types uniformly in each batch element, you can get your application to work. I will investigate a patch to the batch element handling in the client. > ClassCastException in ClientDriver when using CLOB columns and batch updates > ---------------------------------------------------------------------------- > > Key: DERBY-1292 > URL: http://issues.apache.org/jira/browse/DERBY-1292 > Project: Derby > Type: Bug > Versions: 10.1.2.1 > Reporter: Gerald Khin > Assignee: Bryan Pendleton > > java.lang.ClassCastException: java.lang.String > at > org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown > Source) > at > org.apache.derby.client.net.NetStatementRequest.buildSQLDTAcommandData(Unknown > Source) > at org.apache.derby.client.net.NetStatementRequest.writeExecute(Unknown > Source) > at > org.apache.derby.client.net.NetPreparedStatement.writeExecute_(Unknown Source) > at org.apache.derby.client.am.PreparedStatement.writeExecute(Unknown > Source) > at > org.apache.derby.client.am.PreparedStatement.executeBatchRequestX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeBatchX(Unknown > Source) > at org.apache.derby.client.am.PreparedStatement.executeBatch(Unknown > Source) > at CCEBatchUpdateRepro.doInserts(CCEBatchUpdateRepro.java:71) > at CCEBatchUpdateRepro.main(CCEBatchUpdateRepro.java:27) -- 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
