[ http://issues.apache.org/jira/browse/DERBY-941?page=comments#action_12366224 ]
Rick Hillegas commented on DERBY-941: ------------------------------------- Concerning connection events, here is Section 11.2 of the JDBC 4 spec: 70 JDBC 4.0 Specification • October 2005 11.2 Connection Events Recall that when an application calls the method Connection.close, the underlying physical connection—the PooledConnection object—is available for reuse. JavaBeans-style events are used to notify the connection pool manager (the application server) that a PooledConnection object can be recycled. In order to be notified of an event on a PooledConnection object, the connection pool manager must implement the ConnectionEventListener interface and then be registered as a listener by that PooledConnection object. The ConnectionEventListener interface defines the following two methods, which correspond to the two kinds of events that can occur on a PooledConnection object: ■ connectionClosed — triggered when the logical Connection object associated with this PooledConnection object is closed, that is, the application called the method Connection.close ■ connectionErrorOccurred — triggered when a fatal error, such as the server crashing, causes the connection to be lost A connection pool manager registers itself as a listener for a PooledConnection object using the PooledConnection.addConnectionEventListener method. Typically, a connection pool manager registers itself as a ConnectionEventListener before returning a Connection object to an application. The driver invokes the ConnectionEventListener methods connectionClosed and connectionErrorOccurred when the corresponding events occur. Both methods take a ConnectionEvent object as a parameter, which can be used to determine which PooledConnection object was closed or had an error. When the JDBC application closes its logical connection, the JDBC driver notifies the connection pool manager (the listener) by calling the listener's implementation of the method connectionClosed. At this point, the connection pool manager can return the PooledConnection object to the pool for reuse. When an error occurs, the JDBC driver notifies the listener by calling its connectionErrorOccurred method and then throws an SQLException object to the application to notify it of the same error. In the event of a fatal error, the bad PooledConnection object is not returned to the pool. Instead, the connection pool manager calls the PooledConnection.close method on the PooledConnection object to close the physical connection. Concerning statement events, here is section 11.7 of the JDBC4 spec: 11.7 Statement Events If the connection pool manager supports Statement pooling for PreparedStatement objects, it must implement the StatementEventListener interface and then be registered as a listener by that PooledConnection object. The StatementEventListener interface defines the following two methods, which correspond to the two kinds of events that can occur on a PreparedStatement object: ■ statementClosed — triggered when the logical PreparedStatement object associated with this PooledConnection object is closed, that is, the application called the method PreparedStatement.close ■ statementErrorOccurred — triggered when a JDBC driver determines that a PreparedStatement object is no longer valid A connection pool manager registers itself as a listener for a PreparedStatement object using the PooledConnection.addStatementEventListener method. Typically, a connection pool manager registers itself as a StatementEventListener before returning a PreparedStatement object to an application. The driver invokes the StatementEventListener methods statementClosed and statementErrorOccurred when the corresponding events occur. Both methods take a statementEvent object as a parameter, which can be used to determine which PreparedStatement object was closed or had an error. When the JDBC application closes its logical prepared statement, the JDBC driver notifies the connection pool manager (the listener) by calling the listener's implementation of the method statementClosed. At this point, the connection pool manager can return the PreparedStatement object to the pool for reuse. When an error occurs that makes a PreparedStatement object invalid, the JDBC driver notifies the listener by calling its statementErrorOccurred method and then throws an SQLException object to the application to notify it of the same error. > 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 > > 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
