PooledConnectionImpl problem
От | Mike Beachy |
---|---|
Тема | PooledConnectionImpl problem |
Дата | |
Msg-id | 20021206152413.GA23014@marketdude.com обсуждение исходный текст |
Ответы |
Re: PooledConnectionImpl problem
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: