Re: PooledConnectionImpl problem

On 9 Dec 2002, Dave Cramer wrote:
> Mike,
>
> Sorry, I missed this earlier. I am trying to recall who wrote the
> pooling stuff, and at the moment it is escaping me. Can you send us a
> patch if you manage to get it fixed?

    You mean it isn't obvious from the @author tag in the header?
Sorry, I've been out of it for a while too.
    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.
    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.

Aaron

> On Mon, 2002-12-09 at 16:37, Mike Beachy wrote:
> > So, judging by the lack of response to my message below, I assume I'm on
> > my own...
> >
> > One more general question that affects Connection handles retrieved from
> > PooledConnections - use of the Statement.getConnection() method doesn't
> > imply that you are getting a "physical connection", does it? If so, then
> > I suppose the current behavior of the PooledConnectionImpl would be
> > correct.
> >
> > Mike
> >
> > On Fri, Dec 06, 2002 at 10:24:13AM -0500, Mike Beachy wrote:
> > >
> > > Hey all -
> > >
> > > I've found a bug in org.postgresql.jdbc2.optional.PooledConnectionImpl.
> > > The problem is that if you create a java.sql.Statement from
> > > PooledConnectionImpl, then call getConnection() from that Statement, you
> > > get back a java.sql.Connection, not a javax.sql.PooledConnection. So,
> > > statement.getConnection().close() actually closes the physical
> > > connection instead of recycling it to the pool.
> > >
> > > The underlying reason for this is that PooledConnectionImpl is
> > > implemented as a Proxy and doesn't override createStatement() or
> > > prepareStatement() to substitute itself in as the Connection for the
> > > created Statement. (Of course, overriding these methods is not so simple
> > > - an org.postgresql.Jdbc2Statement requires a Jdbc2Connection in its
> > > constructor, and the Proxy only implements java.sql.Connection.)
> > >
> > > I'm hoping that someone familiar with the code can comment on the
> > > following solutions:
> > >
> > > 1. The way that results from trying to keep the Proxy: Change
> > > AbstractJdbc2Connection from an abstract class to an interface
> > > (IJdbc2Connection) and make the Proxy implement IJdbc2Connection instead
> > > of java.sql.Connection. Tweak Jdbc2Statement, Jdbc2PreparedStatement
> > > etc. to use IJdbc2Connection instead of AbstractJdbc2Connection.
> > >
> > > 2. The non-Proxy way: Make PooledConnectionImpl an extension of
> > > Jdbc2Connection. This has the disadvantage noted in the current code
> > > that it won't automatically work for subsequent JDBC revisions. I guess
> > > if it'll work to make an AbstractJdbc2PooledConnection, maybe that can
> > > be worked around, too.
> > >
> > > 3. The lazy, unhelpful way: change my code to stop closing connections
> > > retrieved from getConnection().
> > >
> > > If you have any opinions or insight, or if this all just hopelessly
> > > obtuse, let me know.
> > >
> > > Mike
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 6: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> > >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
>