db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3390) SQLException thrown from user function kills network connection
Date Wed, 24 Sep 2008 18:29:44 GMT

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

Myrna van Lunteren updated DERBY-3390:
--------------------------------------

    Attachment: DERBY-3390_b.diff
                DERBY-3390_a.diff

I'm attaching 2 patches for this.
The first patch I've run suites.All and derbynetclientmats for. the second one I'll do so
shortly...

The two approaches are:
a.  don't cast if the SQLException inside the EmbedSQLException is not also an EmbedSQLException.
b. if the SQLException inside the EmbedSQLException is not also an EmbedSQLException don't
cast, but also check to see if the SQLException has an SQLState. If so, add (SQLState: #####)
to the error message before wrapping in the 38000 error.

The original test case description throws an SQLException without SQLState, I modified the
test case a little to throw this:
        throw new SQLException( "I refuse to return an int!", "5000" ); 

The output of this with the patches is:
output with patch a:
ij> drop function badFunction;
ERROR 42Y55: 'DROP FUNCTION' cannot be performed on 'BADFUNCTION' because it does not exist.
ij> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction' ;
0 rows inserted/updated/deleted
ij> values badfunction();
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int!' was thrown
while evaluating an expression.
ij> disconnect;
ij> exit;

output with patch b:
ij> drop function badFunction;
ERROR 42Y55: 'DROP FUNCTION' cannot be performed on 'BADFUNCTION' because it does not exist.
ij> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction' ;
0 rows inserted/updated/deleted
ij> values badfunction();
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int! (SQLState: 5000)'
was thrown while evaluating an expression.
ij> disconnect;
ij> exit;

Is the saving of the possible SQLState worth the extra code, or is it even necessary at all?
Or just distracting? If ok, is the approach of adding (SQLState: ...) ok? 


> SQLException thrown from user function kills network connection
> ---------------------------------------------------------------
>
>                 Key: DERBY-3390
>                 URL: https://issues.apache.org/jira/browse/DERBY-3390
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
>            Reporter: Rick Hillegas
>            Assignee: Myrna van Lunteren
>         Attachments: DERBY-3390_a.diff, DERBY-3390_b.diff
>
>
> Thanks to Frank Griffin for pointing out this issue in a derby-dev email thread: http://www.nabble.com/SQLException-thrown-from-Table-Function-ResultSet-to15241332.html#a15241332
> If a user-coded function throws a SQLException, Derby will try to cast the exception
to a Derby exception class before shipping the exception to the network client. This raises
a ClassCastException and kills the connection. I have observed this in 10.4, 10.3, 10.2, and
10.1. You can reproduce this problem with the following function class and sql script.
> The function class:
> import java.sql.*;
> public  class   BadFunction
> {
>     /**
>      * <p>
>      * This function just throws a SQLException.
>      * </p>
>      */
>     public  static  int badFunction()
>         throws SQLException
>     {
>         throw new SQLException( "I refuse to return an int!" );
>     }
>     
> }
> Here is the SQL script:
> connect 'jdbc:derby://localhost:8246/derby10.4';
> drop function badFunction;
> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction'
> ;
> values ( badFunction() );
> values ( badFunction() );

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message