db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6214) PreparedStatement.setObject(int, Object, Types.CLOB) fail with DerbyNet
Date Tue, 11 Jun 2013 20:03:21 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680603#comment-13680603
] 

Mike Matrigali commented on DERBY-6214:
---------------------------------------

comments on patch and existing test.  I think at this point the goal for 6214 is to make setObject
work as well as setString, and close out this issue with
the patch.  Then address large strings in another issue.  To this end:

1) you should change comments in ParameterMappingTest that were written before the other issues
were created.  For instance:
    "once DERBY-6214 is fixed, we can remove following check".
2) testDerby6214 is hard to understand what is going on.  Some comments about the i,j loop
would help.  I also would at least rename i to something like numrows.
    helperTest could use more comments also.  I think the various cases could benefit from
some comments like "test small string less that critical xxxx length", 
    test large string greater than xxx length.  The magic numbers for length come from code
path zzz.   would be good to define what large string is and why, maybe a constant with a
comment..
3) in CrossConverters.java:
    o in comments for setObject i think originalSetObject is false in the case of setXXX calls
that are not setObject, but that is not clear from the comments.
    o there is more talk about magic number 32767/3, there should be one constant with a good
name somewhere shared by all the code, and why it is important.
    o it would be nice to fix up comments for setObject that you have added to. it should
start with saying what the routine is doing.  Is the following correct?:

// Convert from string source to target type.
// In support of PS.setXXX, PS.updateXXX, and PS.getXXX 

    o you added the following with no comment as to why, I would prefer not to add an extra
call level to this high traffic routine if possible.  Is it just to save some
       typing to change all the callse in the following setObject routine?  If so I would
just rather see the code change made.  all the overriding based on num arguments can 
       easily lead to bugs when making changes like this, other routine may start getting
called that you don't expect.  :
    final Object setObject(int targetType, Object source) throws SqlException {
        return setObject(targetType, source, false);
    }

4) what problems result if you don't have the originalSetObject information?  It would be
better if we did not have the special case if we can help it, just always send string in small
string case.
    It seems likely there are existing problems with updateXXX also.  maybe just is not right
for getXXX, not sure.  I'd like to see if there is any way to fix this without adding a param/extra
call to
this high traffic routine.


     

                
> PreparedStatement.setObject(int, Object, Types.CLOB) fail with DerbyNet
> -----------------------------------------------------------------------
>
>                 Key: DERBY-6214
>                 URL: https://issues.apache.org/jira/browse/DERBY-6214
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions: 10.8.3.0, 10.9.1.0
>            Reporter: Rong Qu
>            Assignee: Mamta A. Satoor
>         Attachments: Derby6214.java, DERBY6214_patch1_diff.txt, DERBY6214_patch1_stat.txt,
Derby6214_setup.sql, Derby6214_ver2.java, derby.log, DerbyNet_client_test.sql
>
>
> The issue is specific to the DerbyNet client driver, and doesn't seem to occur using
embedded Derby.
>  "PreparedStatement.setObject(int, Object, Types.CLOB)". It seems to be a problem updating
a CLOB column with a parameterized value using the DerbyNet client driver, and if the update
SQL ends up updating more than one row. I attached a simple test case that just uses JDBC
to reproduce the error. The exception looks like this:
> org.apache.derby.client.am.BatchUpdateException: Non-atomic batch failure.  The batch
was submitted, but at least one exception occurred on an individual member of the batch. Use
getNextException() to retrieve the exceptions for specific batched elements.
>     at org.apache.derby.client.am.Agent.endBatchedReadChain(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)
>     ...
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element #0: An unexpected
exception was thrown
>     at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
>     at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source)
>     at org.apache.derby.client.net.NetStatementReply.readExecute(Unknown Source)
>     at org.apache.derby.client.net.StatementReply.readExecute(Unknown Source)
>     at org.apache.derby.client.net.NetPreparedStatement.readExecute_(Unknown Source)
>     at org.apache.derby.client.am.PreparedStatement.readExecute(Unknown Source)
>     ... 4 more
> Caused by: org.apache.derby.client.am.SqlException: Error for batch element #0: Java
exception: 'Stream has already been read and end-of-file reached and cannot be re-used.: java.io.EOFException'.
>     at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
>     at org.apache.derby.client.am.SqlException.<init>(Unknown Source)
>     ... 10 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message