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-941) Add JDBC4 support for Statement Events
Date Tue, 18 Apr 2006 09:37:18 GMT
     [ http://issues.apache.org/jira/browse/DERBY-941?page=all ]

Knut Anders Hatlen updated DERBY-941:
-------------------------------------

    Attachment: ListenerTest.java

I have read what the spec says about statement event listeners, but it
is still not quite clear to me how they are supposed to work.

The javadoc for StatementEventListener.statementErrorOccurred() says:

  The driver calls this method on all StatementEventListeners
  registered on the connection when it detects that a
  PreparedStatement is invalid. The driver calls this method just
  before it throws the SQLException, contained in the given event, to
  the application.

Does this mean that no more than one statementErrorOccurred event
should be sent per PreparedStatement? I think so, since the statement
becomes invalid once, right?

I'm also not sure exactly how one determines that a statement is
invalid. It seems like checkStatementValidity() considers a statement
invalid when it sees an SQLSTATE in class 42 (syntax error or access
rule violation).

I wrote a test program (ListenerTest.java) which does the following:

  1. create table "mytable"
  2. prepare statement "select * from mytable"
  3. execute prepared statement
  4. drop table "mytable"
  5. execute prepared statement
  6. execute prepared statement
  7. recreate table "mytable"
  8. execute prepared statement
  9. close prepared statement

I get an exception and an error-occurred event in step 5 and step 6,
and a closed event in step 9.

I'm not sure what I should expect, but what puzzles me is

  1) I get two error-occurred events on the same statement (that is,
     I'm told twice that the statement is invalid)

  2) Even though I'm told that the statement is invalid, I'm able to
     execute it successfully in step 8

> Add JDBC4 support for Statement Events
> --------------------------------------
>
>          Key: DERBY-941
>          URL: http://issues.apache.org/jira/browse/DERBY-941
>      Project: Derby
>         Type: New Feature

>   Components: JDBC
>     Versions: 10.0.2.0
>     Reporter: Rick Hillegas
>     Assignee: V.Narayanan
>  Attachments: ListenerTest.java, statementeventlisteners_embedded.diff, statementeventlisteners_embedded.stat,
statementeventlisteners_embedded_v2.diff, statementeventlisteners_embedded_v2.stat, statementeventlisteners_embedded_ver1.html
>
> As described in the JDBC 4 spec, sections 11.2, 11.7,  and 3.1.
> These are the methods which let app servers listen for connection and statement closure
and invalidation events.
> Section 11.2 of the JDBC 4 spec explains connection events: Connection pool managers
which implement the ConnectionEventListener interface can register themselves to listen for
 "connectionClosed" and fatal "connectionErrorOccurred" events. App servers can use these
events to help them manage the recycling of connections back to the connection pool.
> Section 11.7 of the JDBC 4 spec explains statement events: Statement pools which implement
StatementEventListener can register themselves to listen for "statementClosed" and "statementErrorOccurred"
events. Again, this helps statement pools manage the recycling of statements back to the pool.

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