[
https://issues.apache.org/jira/browse/DERBY-3085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531116
]
A B commented on DERBY-3085:
----------------------------
Hi Kathey,
I don't have much experience in this area of code, but from what I could tell
the patch looks good. The changes are nicely contained and easy to understand,
and I verified that the new regression test case fails without the patch and
passes with it.
So +1 from me, inexperienced with LOBs though I am...
I did have the following minor comments/suggestions, but none of these is worth
blocking the commit of your changes:
1 - Your comment above says "There is only one parameter ever streamed", and a
similar comment in the patch says "Only the last parameter with an EXTDTA will
be streamed." It might be nice to have more of a "why" in the code comment, or
else a reference to another place that explains this more. As a reader of the
patch, that was the first thing I found myself wondering, and I was not able to
find an explanation in the (very) brief scanning that I did.
2 - It looks like we drain the buffer 1000 bytes at a time; is that just a
randomly chosen number? I'm guessing it is but just thought I'd ask. If the
number itself is not significant, a quick comment saying as much might make it
easier for people to change it in the future if needed (for whatever reason).
3 - Is it possible to add a test case where we have multiple stream parameters,
just to make sure that things still work in that case, too? Ex. add a second
lob column to "testing" table and then a second parameter to the UPDATE
statement?
3 - It looks like the regression test added for this issue only tests the case
of a "testing" table with no rows. Would it be worth it (as a sanity check) to
also test the situation where there are rows in the table but the UPDATE
predicate does not match any of the rows? I assume that such an UPDATE will
behave the same as when there are no rows, but it may be useful to verify.
4 - Looks like there may be some slight spacing inconsistencies within the
changed code for DRDAStatement.java.
As I said, all of these comments are minor. The patch looks good overall.
Thank you for picking this issue up and for resolving it so quickly!
> Fails to handle BLOB fields with a PreparedStatement with size >32750 bytes
> ---------------------------------------------------------------------------
>
> Key: DERBY-3085
> URL: https://issues.apache.org/jira/browse/DERBY-3085
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Network Client
> Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4
> Environment: Windows XP SP2
> Reporter: Mikael Aronsson
> Assignee: Kathey Marsden
> Attachments: derby-3085_diff.txt, derby-3085_stat.txt, TestBlob.java,
> trace.out.norows, trace.out.withrow
>
>
> Java Version: 1.6.0_02
> Java Vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jre1.6.0_02
> Java classpath: derbytools.jar
> OS name: Windows XP
> OS architecture: x86
> OS version: 5.1
> Java user name: Ma
> Java user home: C:\Documents and Settings\ma
> Java user dir: c:\tools\derby\lib
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> --------- Derby Information --------
> JRE - JDBC: Java SE 6 - JDBC 4.0
> [C:\tools\derby\lib\derbytools.jar] 10.3.1.4 - (561794)
> The following code fails:
> // Data is a byte[] vector
> ByteArrayInputStream is = new ByteArrayInputStream( data);
> String sql = "UPDATE MyTable SET FContents=? WHERE FName='" + name + "'";
> PreparedStatement ps = conn.prepareStatement( sql);
> ps.setBinaryStream( 1, is, data.length);
>
> if( ps.executeUpdate() == 0)
> {
> // it throws an exception here if the data array us larger then
> around 32750 bytes!!!
> }
> It look's like when the size of the data[] vector is > 32750 bytes or so it
> throws an exception like this:
> java.sql.SQLException: A network protocol error was encountered and the
> connection has been terminated: A PROTOCOL Data Stream Syntax Error was
> detected. Reason: 0x0. Plaintext connection attempt to an SSL enabled server?
> at
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeUpdate(Unknown
> Source)
> The table is defined as:
> CREATE TABLE MyTable (FName varchar(300) NOT NULL,FContents BLOB(16M) NOT
> NULL)
> It does loook like this only happens with the NetWork client driver, the
> embedded driver works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
