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