db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6214) PreparedStatement.setObject(int, Object, Types.CLOB) fail with DerbyNet
Date Mon, 20 May 2013 15:47:17 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mamta A. Satoor updated DERBY-6214:
-----------------------------------

    Attachment: Derby6214_ver2.java

I have been working on this jira for a little bit, specifically on the stand alone test case.
I am attaching the test case as Derby6214_ver2.java. This test case is built on top of the
test cases provided by Rong and Kathey. While working on the test, I found that we do not
need to have batch processing to run into the problem so I have removed the batch add and
execution part to make the test case simpler. The test creates the table(by first dropping
the table if already exists) and loads data into it. (Change the url for the derby database
as appropriate. Right now, the db location hard coded as c:/dellater/ClobTest).

The test can be used to test both embedded and client server. Additionally, it shows that
the workaround of using setString instead of setObject in client server case does not work
for a fairly large string. 


The test takes three parameters
The first param
   if "client" is passed then test case will be run in network server environment. For this,
you first have to start the
	network server before running the test.
   if not "client" is passed then test case will be run in embedded derby.
The second parameter 
   if '1' is passed then test case will update only one row(this verifies that we work fine
updating clob with just one row update)
   if not '1', then test case will update two rows(this is one which runs into the bug)
The third parameter says to use the workaround of using setString instead of setObject
   if '1' is passed then test case will use the workaround of using setString rather than
setObject on the clob column
	using a small string
   if '2' is passed then test case will use the workaround of using setString rather than
setObject on the clob column
	using a very large string
   if '3' is passed then test case will use setObject on the clob column using small string
   if anything other than '1' or '2' or '3' is passed then test case will use setObject on
the clob column using 
	a very large string

Now, here is the behavior for all these scenarios. I realize that this sounds pretty involved
but it helps us establish what cases work and what cases break.

Embed test cases work for all different combinations as shown below
1)Embed test case updating only one row and using setString with small string - works fine
	java Derby6214_ver2 embed 1 1
2)Embed test case updating only one row and using setString with very large string - works
fine
	java Derby6214_ver2 embed 1 2
3)Embed test case updating only one row and using setObject with small string - works fine
	java Derby6214_ver2 embed 1 3
4)Embed test case updating only one row and using setObject with very large string - works
fine
	java Derby6214_ver2 embed 1 4
5)Embed test case updating two rows and using setString with small string - works fine
	java Derby6214_ver2 embed 2 1
6)Embed test case updating two rows and using setString with very large string - works fine
	java Derby6214_ver2 embed 2 2
7)Embed test case updating two rows and using setObject with small string - works fine
	java Derby6214_ver2 embed 2 3
8)Embed test case updating two rows and using setObject with very large string - works fine
	java Derby6214_ver2 embed 2 4
In short, all the variations work in the embedded case.

Moving on to the client server case.
1)Client server test case updating only one row and using setString with small string - works
fine
	java Derby6214_ver2 client 1 1
2)Client server test case updating only one row and using setString with very large string
- works fine
	java Derby6214_ver2 client 1 2
3)Client server test case updating only one row and using setObject with small string - works
fine
	java Derby6214_ver2 client 1 3
4)Client server test case updating only one row and using setObject with very large string
- works fine
	java Derby6214_ver2 client 1 4
5)Client server test case updating two rows and using setString with small string - works
fine
	java Derby6214_ver2 client 2 1
6)Client server test case updating two rows and using setString with very large string - FAILS
	java Derby6214_ver2 client 2 2
7)Client server test case updating two rows and using setObject with small string - FAILS
	java Derby6214_ver2 client 2 3
7)Client server test case updating two rows and using setObject with very large string - FAILS
	java Derby6214_ver2 client 2 4

Once the test is compiled, an eg of using the test for embedded updating just one row and
using setString to update CLOB column with a small string would be as follows
java Derby6214_ver2 embed 1 1

                
> 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
>         Attachments: Derby6214.java, 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