Re: statement caching patch from Laszlo Hornyak for review

Csaba Nagy wrote:
>> In fact, how about kicking our connection pool implementation out to an
>> external module as well? The connection pool and the statement cache
>> could live together as a pgfoundry project, or as an additional jar in
>> the jdbc project.
>
> The postgres ConnectionPool implementation included in the JDBC project
> already has some postgres specific bits (e.g. setPreparedThreashold),
> and I find it is not specific enough, as it is quite hard to set
> postgres specific settings on the pooled connections otherwise, as the
> place where the pool is configured is the natural place where all other
> default connection properties should be configured too. So my opinion is
> to make the ConnectionPool implementation as specific for postgres as it
> is reasonable, allowing to set most of the things you could set on a
> postgres connection. In particular it would be nice to set the default
> properties to pass on when creating a new pooled connection (this is
> actually not really postgres specific now that I think about it, but
> prepareThreshold is).

You could have extra methods to set any driver-specific properties in
the generic connection pool implementation. With reflection, I think you
could also create a proxy DataSource class that implements all the same
driver-specific methods as the underlaying DataSource.

What do you think of the idea of just moving the current implementation
to an additional jar?

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com