db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-941) Add JDBC4 support for Statement Events
Date Mon, 13 Feb 2006 18:29:32 GMT
    [ 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


Mime
View raw message