[
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
