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 Wed, 26 Apr 2006 12:33:04 GMT
    [ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12376479 ] 

Knut Anders Hatlen commented on DERBY-941:

Looks good, but I have some questions/comments:

* Should ClientJDBCObjectFactory40.newPreparedStatement() have
  returned a PreparedStatement40 object instead of PreparedStatement?

* New field pooledConnnection_ in NetConnection is spelled incorrectly
  (three n's). It would also be good if it had a comment explaining
  what its purpose is.

* New field pooledConnection_ in PreparedStatement could be final, I

* Javadoc for ClientPooledConnection.onStatementErrorOccurred() is
  identical to onStatementClose().

* Javadoc for ClientPooledConnection40.onStatementErrorOccurred()
  doesn't have @param tag for the second parameter.

* Sentences in javadoc comments should start with a capital letter and
  end with a period, otherwise they are hard to read when the html is

* Many of the @param tags lack a description, or only the type of the
  parameter is put into the description.

* The javadoc for many of the constructors of PreparedStatement and
  NetPreparedStatement start with "It has the ClientPooledConnection
  as one of its parameters". It would be better if the first sentence
  said something about what the constructors do, since the first
  sentence used in the summary when generating html.

* Two of the ClientJDBCObjectFactory.newPreparedStatement() methods
  have a double set of javadoc comments.

> 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_client.diff, statementeventlisteners_client.html,
statementeventlisteners_client.stat, statementeventlisteners_embedded.diff, statementeventlisteners_embedded.stat,
statementeventlisteners_embedded_v2.diff, statementeventlisteners_embedded_v2.stat, statementeventlisteners_embedded_v3.diff,
statementeventlisteners_embedded_v3.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