Skip site navigation (1) Skip section navigation (2)

Re: Connection and Statement

From: "Nick Fankhauser" <nickf(at)ontko(dot)com>
To: <ambre(at)ebutec(dot)com>, <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Connection and Statement
Date: 2001-11-08 13:59:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc

In reply to both of these questions, I can relate my experiences, but as to
the "right" answer, the folks who actually wrote the driver will need to
weigh in.

> 1. Are there limitations creating statements from a connection.

We have a connection pool class that has been tested with 16 open
connections, each having about 30 prepared statements established. (A
"PreparedConnectionPool") This doesn't seem to have broken anything and the
performance is better than either prepared statements alone or a connection
pool alone. (We haven't done serious benchmarking, but the difference is

> 2. When I use a connection pool which keeps all initialized connection
> open, when is the earliest time I can put  an already retrieved
> connection back. Can I put the connection back, before I have closed all
> created statements, or is this not good practice.

Our pool class closes unused connections without closing the statements
opened for the connection. Since the javadoc for close() says "Releases this
Statement object's database and JDBC resources immediately instead of
waiting for this to happen when it is automatically closed.", I took that to
imply that garbage collection would take care of this if we yanked the
connection out from under the statement. So far, we've not experienced any
problems with this approach.


Nick Fankhauser  nickf(at)ontko(dot)com  Phone 1.765.935.4283  Fax 1.765.962.9788
Ray Ontko & Co.     Software Consulting Services

In response to


pgsql-jdbc by date

Next:From: Jacob Vennervald MadsenDate: 2001-11-08 14:03:57
Subject: JDBC driver
Previous:From: Jochem van DietenDate: 2001-11-08 13:51:48
Subject: Re: Storing a tree

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group