db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1292) ClassCastException in ClientDriver when using CLOB columns and batch updates
Date Sat, 06 May 2006 15:34:22 GMT
    [ 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

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:
>     Reporter: Gerald Khin
>     Assignee: Bryan Pendleton

> java.lang.ClassCastException: java.lang.String
> 	at org.apache.derby.client.net.NetStatementRequest.computeProtocolTypesAndLengths(Unknown
> 	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:
For more information on JIRA, see:

View raw message