openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Abe White (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-699) SQLWarnings not handled properly with WarningAction set to "handle"
Date Mon, 25 Aug 2008 18:33:44 GMT

    [ https://issues.apache.org/jira/browse/OPENJPA-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625452#action_12625452
] 

Abe White commented on OPENJPA-699:
-----------------------------------

If Joe is right then neither my proposed solution nor the attached patch are acceptable. 
We need to capture the output of both the exception and any warnings.  So I propose the following
changes to LoggingConnectionDecorator:

1. Change the following pattern: 
try {...} catch(SQLException se) { throw wrap(se...); } finally { ... handleSQLWarnings(...);
}
to:
SQLException err = null;
try {...} catch(SQLException se) { err = wrap(se...); } finally { ... handleSQLErrors(...,
err); }

2. Change all the handleSQLWarnings methods except handleSQLWarnings(SQLWarning) to be named
handleSQLErrors and to accept an extra SQLException argument.  The try/finally blocks in these
methods will become try/catch/finally blocks where the catch captures the thrown exception.
 At the end of the method we combine the passed-in exception with the thrown exception and
throw the result as a single exception (unless either/both are null of course, in which case
we throw the non-null one or nothing at all).  

3. Fix all the prepareStatement/createStatement methods that currently don't have handleSQLWarnings
in a finally block at all to use a try/catch/finally block as outlined in change #1 above.

Does that sound acceptable?  We might still get extraneous "The statement has been closed"
output in the combined exceptions we throw under certain drivers, but at least no information
will get lost.

> SQLWarnings not handled properly with WarningAction set to "handle"
> -------------------------------------------------------------------
>
>                 Key: OPENJPA-699
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-699
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: diagnostics
>    Affects Versions: 1.0.0
>         Environment: Kodo 4.1.4
> OpenJPA 1.0.0
> MS SQL 2005
> MS JDBC DRIVER VERSION  1.1 
> JDK 1.5
>            Reporter: Xiaoqin Feng
>         Attachments: openJPA-699.patch
>
>
> If set  "kodo.ConnectionFactoryProperties" "warningAction" to "throw" or "handle", when
an INSERT statement fails due 
> to an attempt to insert null into a non-null column, log output is  "The statement has
been 
> terminated".
> If didn't set  "warningAction", the default value is "ignore". It logs correct SQLException
which is as follows:
> Cannot 
> insert the value NULL into column 'TestTimeNotNullNoDefaultUtc', table 
> 'STADatabase.dbo.DefaultValuesJ'; column does not allow nulls. INSERT fails. 
> {prepstmnt 112461492 
> ... ...
> In org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.LoggingPreparedStatement.executeUpdate(),
the 
> code is
>             public int executeUpdate(String sql) throws SQLException {
>                 _sql = sql;
>                 logSQL(this);
>                 long start = System.currentTimeMillis();
>                 try {
>                     return super.executeUpdate(sql);
>                 } catch (SQLException se) {
>                     throw wrap(se, LoggingStatement.this);
>                 } finally {
>                     logTime(start);
>                     handleSQLWarning(LoggingStatement.this);
>                 }
>             }
> In this test case, it got a SQLWarning with msg 'The statement has been 
> terminated' and a SQLException which tells Column null is not allowed.
> When WarningAction is set to 'throw' or 'handle' and if handle doesn't 
> consume the warning but throw it, the SQLWarning is thrown from finally 
> block.
> The SQLWarning which it is a subclass of SQLException will be processed by 
> DBdictionary.newStoreException() so we see the incorrect message.

-- 
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