Re: statement caching patch from Laszlo Hornyak for review - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: statement caching patch from Laszlo Hornyak for review
Date
Msg-id 96F22561-D20B-4BD2-8C5C-1E83953DAA4C@fastcrypt.com
Whole thread Raw
In response to Re: statement caching patch from Laszlo Hornyak for review  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: statement caching patch from Laszlo Hornyak for review
List pgsql-jdbc
Heikki,

I posted the proof of concept back in June of last year, and again in
March.

I searched the archives but was unable to find where you voiced this
opinion ?

Either way, the patch is written in such a way to be very non-
invasive to the driver, and the code
will only ever be executed (except for a single if statement) if the
user enables the feature.

Can you be more specific about why you want this as a separate module ?

Dave
On 1-Aug-07, at 4:31 PM, Heikki Linnakangas wrote:

> 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend


pgsql-jdbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: statement caching patch from Laszlo Hornyak for review
Next
From: Heikki Linnakangas
Date:
Subject: Re: statement caching patch from Laszlo Hornyak for review