Re: PooledConnectionImpl problem

On Mon, 9 Dec 2002, Mike Beachy wrote:

> So, judging by the lack of response to my message below, I assume I'm on
> my own...

I know Barry Lind, one of the key maintainers is on vacation at the
moment. I am interested in this issue as well, but haven't had the time
to a look at it in detail.

My initial reaction to your concerns of turning the PooledConnectionImpl
into a Jdbc2Connection is that it might be able to be solved by an
explicit cast somewhere. It seems that anything using the jdbc2 optional
package must be backed by a real Jdbc2Connection even if that isn't clear
from the "extends" and "implements" attributes of the class definitions.

Kris Jurka

> 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
>