db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1364) Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
Date Sat, 24 Jun 2006 10:02:30 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1364?page=all ]

Knut Anders Hatlen updated DERBY-1364:

    Attachment: derby-1364-v1.diff

Attached a patch (derby-1364-v1.diff) which attempts to fix this
issue. Description of the patch:

1. Checking of the number of result sets returned was moved from
   executeUpdate/executeQuery to a point in flowExecute where the
   transaction has not been auto-committed (otherwise, the transaction
   would already be committed when the exception was raised).

2. If the number of result sets does not match the execute type and
   auto-commit is enabled, the transaction is rolled back (otherwise,
   the transaction would be committed when the Statement was closed or

3. All execute* methods in CallableStatement were removed since they
   have become identical to the methods in PreparedStatement. (Or
   almost identical. The methods in CallableStatement did not call
   checkStatementValidity() on errors, but that's probably a bug.)

4. SQL state for error message in executeQuery() was changed to match
   embedded (XJ201/XJ205 -> X0Y78). Updated English and Portuguese
   messages to use the new SQL state (no other translations existed
   for XJ201 and XJ205).

5. Added more rollback tests to jdbcapi/ProcedureTest.junit and
   enabled all test cases for DerbyNetClient.

I have run derbyall with no failures except runtimeinfo.java which
fails all the time. The patch is ready for review. Thanks!

> Client driver does not roll back the effects of a stored procedure when incorrectly invoked
by executeQuery()/executeUpdate()
> -----------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1364
>          URL: http://issues.apache.org/jira/browse/DERBY-1364
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions:,
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen
>     Priority: Minor
>      Fix For:
>  Attachments: derby-1364-v1.diff, derby-1364-v1.stat
> When executing a stored procedure with executeQuery() and the proc
> doesn't return exactly one result set, the query should fail and the
> statement should be rolled back. Embedded does this correctly.
> The client driver, however, does not roll back the statement, so the
> effects of statements executed on nested connections in the stored
> procedure are still visible. The reason for this is that the network
> server executes the statement with execute() instead of
> executeQuery(), so that it succeeds on the server. The client then
> counts the number of result sets, and raises an exception if it is not
> one, but it does not roll back the effects of the stored procedure.
> verified that.)
> The same problem exists for executeUpdate(). JCC also has these
> problems.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message