Re: PooledConnectionImpl problem - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: PooledConnectionImpl problem |
Date | |
Msg-id | 1039482028.1953.65.camel@inspiron.cramers Whole thread Raw |
In response to | Re: PooledConnectionImpl problem (Mike Beachy <beachy@marketboy.com>) |
Responses |
Re: PooledConnectionImpl problem
|
List | pgsql-jdbc |
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? Dave 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 -- Dave Cramer <Dave@micro-automation.net>
pgsql-jdbc by date: