Re: PooledConnectionImpl problem - Mailing list pgsql-jdbc

On Tue, Dec 10, 2002 at 05:47:00PM -0500, Aaron Mulder wrote:
>     Mike, as for the issues below, it would be best if the Statement,
> PreparedStatement, and CallableStatement all use a handler that hands back
> a PooledConnectionImpl, not a Connection or PooledConnection.  It's easy
> enough for the ConnectionHandler to hand out further proxies.  I can send
> along a patch for this.

Not sure what you mean here - at least, I can't see any way this would
fix the problem.

>     I don't follow the specific arguments you're making with regard to
> constructors and whatnot -- we're never going to be constructing a new
> Statement, just wrapping the one that's already returned by the real
> Connection, as ConnectionHandler wraps a Connection.

Okay - some terminology just to make sure I'm on the same page.

Connection handle: a generic term applied to the object that is given
out by PooledConnection.getConnection(). It acts just like a Connection
to the user. When close() is called on a Connection handle it is
returned to the pool, but the physical connection is not closed.

ConnectionHandler: Aaron's implementation of a Connection handle. It
implements the Connection interface, but is not a Jdbc2Connection,
because it uses java.reflect.Proxy to implement the interface.

Aaron, how is it that we're never going to be constructing a new
Statement?  Ack. I'm tired and likely to spout nonsense if I try to go
into this now.  Here's a test that can be added to ConnectionPoolTest
that should fail for the current code. Can you make it work?

        public void testStatementConnection()
        {
                try
                {
                        PooledConnection pc = getPooledConnection();
                        Connection con = pc.getConnection();
                        Statement s = con.createStatement();
                        Connection conRetrieved = s.getConnection();
                        assertTrue(con.getClass().equals(conRetrieved.getClass()));
                        assertTrue(con.equals(conRetrieved));
                }
                catch (SQLException e)
                {
                        fail(e.getMessage());
                }
        }

Mike


p.s. I think I see what you mean now - createStatement() gets added to
ConnectionHandler as one of the intercepted methods; it calls
createStatement() on the real Connection, but wraps the result in a
Statement proxy that intercepts calls to getConnection and returns the
Connection proxy instead of the actual Connection?

You are in a maze of twisty proxies, all alike...