Tests a PooledConnection implementation provided by a JDBC driver. Test case
provided by Johnny Macchione from bug database record BUG#884. According to
the JDBC 2.0 specification:
"Each call to PooledConnection.getConnection() must return a newly
constructed Connection object that exhibits the default Connection behavior.
Only the most recent Connection object produced from a particular
PooledConnection is open. An existing Connection object is automatically
closed, if the getConnection() method of its associated Pooled-Connection is
called again, before it has been explicitly closed by the application. This
gives the application server a way to �take away� a Connection from the
application if it wishes, and give it out to someone else. This capability
will not likely be used frequently in practice."
"When the application calls Connection.close(), an event is triggered that
tells the connection pool it can recycle the physical database connection. In
other words, the event signals the connection pool that the PooledConnection
object which originally produced the Connection object generating the event
can be put back in the connection pool."
"A Connection-EventListener will also be notified when a fatal error occurs,
so that it can make a note not to put a bad PooledConnection object back in
the cache when the application finishes using it. When an error occurs, the
ConnectionEventListener is notified by the JDBC driver, just before the
driver throws an SQLException to the application to notify it of the same
error. Note that automatic closing of a Connection object as discussed in the
previous section does not generate a connection close event."
The JDBC 3.0 specification states the same in other words:
"The Connection.close method closes the logical handle, but the physical
connection is maintained. The connection pool manager is notified that the
underlying PooledConnection object is now available for reuse. If the
application attempts to reuse the logical handle, the Connection
implementation throws an SQLException."
"For a given PooledConnection object, only the most recently produced logical
Connection object will be valid. Any previously existing Connection object is
automatically closed when the associated PooledConnection.getConnection
method is called. Listeners (connection pool managers) are not notified in
this case. This gives the application server a way to take a connection away
from a client. This is an unlikely scenario but may be useful if the
application server is trying to force an orderly shutdown."
"A connection pool manager shuts down a physical connection by calling the
method PooledConnection.close. This method is typically called only in
certain circumstances: when the application server is undergoing an orderly
shutdown, when the connection cache is being reinitialized, or when the
application server receives an event indicating that an unrecoverable error
has occurred on the connection."
Even though the specification isn't clear about it, I think it is no use
generating a close event when calling the method PooledConnection.close(),
even if a logical Connection is open for this PooledConnection, bc the
PooledConnection will obviously not be returned to the pool.
author: fcr |