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] Commented: (DERBY-941) Add JDBC4 support for Statement Events
Date Tue, 18 Apr 2006 12:03:18 GMT
    [ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12374914 ] 

Knut Anders Hatlen commented on DERBY-941:

Hi Anurag,

I'm not sure if the statement was invalid. That, I guess, depends on
the definition of invalid (you could perhaps say it was temporarily
invalid). The javadoc for StatementEventListener refers to a similar

  For some databases, a statement becomes invalid if a DDL operation
  is performed that affects the table. For example an application may
  create a temporary table to do some work on the table and then
  destroy it. It may later recreate the same table when it is needed
  again. Some databases will invalidate any prepared statements that
  reference the temporary table when the table is dropped.

Since Derby allows you to use the same prepared statement after the
table is recreated, I would say that the statement was not invalid,
and that a statementErrorOccurred event should not be raised.

Maybe prepared statements are invalidated only when the connection
fails or the statement is closed?

> 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:
>     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:
For more information on JIRA, see:

View raw message