db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1178) NetworkServer doesn't handle new subclasses of SQLException correctly
Date Mon, 10 Apr 2006 15:59:00 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1178?page=all ]

Rick Hillegas updated DERBY-1178:
---------------------------------

    Attachment: bug1178_rev1.diff

I have attached bug1178_rev1.diff, which supplies a fix to this issue. The patch also eliminates
a boatload of jdk16-specific test canons. Here is a description of the patch:

The problem, as Dyre notes, arises because of the peculiar way that we serialize SQLExceptions
across DRDA. This is what we do:

1) The server breaks open the Derby exception and scrapes out the Derby message ID and its
arguments. These scraps are then encoded into a string and sent across DRDA.

2) The client, on receiving this encoded string, decodes the message ID and args, then asks
the server to translate the message into the language preferred by the client.

This is a fair amount of fragile jiggery-pokery for ferrying and localizing SQLExceptions
across DRDA. You might want to think about how, given a more stateful session, the server
could localize the message text in the first place, eliminating the handshake in (2). However,
this raises backward compatibility issues which I'm not itching to address in this release.

The current approach breaks under JDBC4 because the server no longer holds a Derby exception.
Instead, the server holds one of the JDBC4-introduced subclasses of SQLException. These sublcasses
do not contain the Derby message ID and its arguments. With nothing to encode, the serialization
falls on its face.

My solution to this problem is to poke the Derby exception into the cause field of the JDBC4-introduced
SQLException. By looking inside the wrapped Derby exception, the serialization logic can find
the message ID and its args.

Derbyall ran "cleanly" (modulo expected diffs in wisconsin) under jdk1.4. Derbyall also ran
cleanly (modulo the wisconsin diffs) under jkd16 except for some diffs in lang/procedure and
lang/updatableResultSet. I have updated their jdk16-specific canons and I believe derbyall
now runs under jdk1.6 as well as it runs under jdk1.4. The jdbc4 tests also run cleanly.

Here are the files touched by this patch:

M      java\engine\org\apache\derby\impl\jdbc\SQLExceptionFactory.java
M      java\engine\org\apache\derby\impl\jdbc\SQLExceptionFactory40.java
M      java\engine\org\apache\derby\impl\jdbc\Util.java
M      java\drda\org\apache\derby\impl\drda\DRDAConnThread.java
M      java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\Stream.java
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\holdCursorJDBC30.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\importExport.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\LOBTest.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\savepointJdbc30_JSR169.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\prepStmt.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\checkSecMgr.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\unaryArithmeticDynamicParameter.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\metadata.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\setTransactionIsolation.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\users2.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\procedure.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\forupdate.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\resultset.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\nullSQLText.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\ieptests.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\holdCursorJavaReflection.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\blobclob4BLOB.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\users.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\testij.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\csPrepStmt.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\optimizerOverrides.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\syscat.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\odbc_metadata.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\holdCursorIJ.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\secureUsers.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\jdk16\supersimple.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\Stream.out
M      java\testing\org\apache\derbyTesting\functionTests\master\jdk16\closed.out
A      java\testing\org\apache\derbyTesting\functionTests\master\jdk16\dblook_test.out
M      java\testing\org\apache\derbyTesting\functionTests\master\jdk16\releaseCompileLocks.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\importExport.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\unaryArithmeticDynamicParameter.ou
t
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\metadata.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\setTransactionIsolation.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\holdCursorJava.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\procedure.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\Stream.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\ieptests.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\blobclob4BLOB.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\holdCursorJavaReflection.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\xaSimplePositive.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\syscat.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\odbc_metadata.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\supersimple.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\holdCursorJDBC30.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\savepointJdbc30_JSR169.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\LOBTest.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\updatableResultSet.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\prepStmt.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\checkSecMgr.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\users2.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\savepointJdbc30_XA.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\forupdate.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\resultset.out
M      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\parameterMapping.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\nullSQLText.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\users.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\testij.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\csPrepStmt.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\optimizerOverrides.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\holdCursorIJ.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\secureUsers.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk16\XATest.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\Stream.out
D      java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\jdk14\Stream.out
M      java\testing\org\apache\derbyTesting\functionTests\master\Stream.out


> NetworkServer doesn't handle new subclasses of SQLException correctly
> ---------------------------------------------------------------------
>
>          Key: DERBY-1178
>          URL: http://issues.apache.org/jira/browse/DERBY-1178
>      Project: Derby
>         Type: Sub-task

>   Components: JDBC, Localization, Network Server, Regression Test Failure
>     Versions: 10.2.0.0
>     Reporter: Dyre Tjeldvoll
>     Assignee: Rick Hillegas
>     Priority: Critical
>      Fix For: 10.2.0.0
>  Attachments: bug1178_rev1.diff
>
> I observe a strange diff when running metadata.java under 1.6 and
> NetworkServer.
> Some expected SQLExceptions that are printed in the output have ' : '
> appended to them, and this causes a diff.
> After some debugging and poking around I discovered that this is
> because
> DRDAConnThread::buildSqlerrmc(SQLException se) 
> assumes that if 'se' is NOT an EmbedSQLException it should not build a
> tokenized sqlerrmc:
> 		if (se instanceof EmbedSQLException  && ! severe)
> 			sqlerrmc = buildTokenizedSqlerrmc((EmbedSQLException) se);
> 		else {
> 		    System.out.println("using preformatted..."); 
> 			// If this is not an EmbedSQLException or is a severe excecption where
> 			// we have no hope of succussfully calling the SYSIBM.SQLCAMESSAGE send
> 			// preformatted message using the server locale
> 			sqlerrmc = buildPreformattedSqlerrmc(se);
> 			}
> But in Java 1.6 'se' can indeed be something else, e.g.
> java.sql.SQLSyntaxErrorException
> in this case the NetworkServer will build a preformatted message, and
> SYSIBM.SQLCAMESSAGE will be called on this. Unfortunately  the input
> is not checked very well so it ends up trying to use the preformatted
> message as a real messageId and try to look up a localized version of
> the message. This obviously doesn't work and in the bail-out process we end up
> with the preformatted message with ' : ' appended to it...
> So I think DRDAConnThread::buildSqlerrmc(SQLException se) must be able
> to handle all the new SQLException types.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message