Fwd: Caching driver on pgFoundry?

The mail below didn't make onto the list. Reason: I sent with the
wrong FROM address. Why do I have several e-mail addresses? Because
the e-mail address "peter(dot)kovacs(dot)1(dot)0rc(at)gmail(dot)com" was not
accepted/handled/seen/whatever by the postgres mail list server.
(Sorry for my having a troubled life.)

---------- Forwarded message ----------
From: Peter Kovacs <peter(dot)kovacs(dot)1(dot)0rc(at)gmail(dot)com>
Date: Sep 6, 2007 9:38 AM
Subject: Re: [JDBC] Caching driver on pgFoundry?
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>,
Heikki Linnakangas <heikki(at)enterprisedb(dot)com>,
pgsql-jdbc(at)postgresql(dot)org

> If this is the case then I would argue that having caching in the
> appserver is a great idea for everyone using an appserver it does not
> help the rest of the world that doesn't use an app server.

We have a product that doesn't use app server, still we need a cached
connection pool. In this case this is an Oracle backend, so we started
using the cached pool implementation found in the Oracle jdbc driver
-- assuming that Oracle will do caching/pooling best for its
Connections. The fact is that we've been having some issues with the
Oracle cached pool implementation, so I started to extensively test
the Apache DBCP and the issues seems to have gone away.

Apart from parabolic example above, I think that from a "global"
perspective, it would be much more reasonable to help the Apache
people solve any issue which someone using the Commons DBCP with
PostgreSQL might have than doing your own little house work excercise
of implementing yet-another-ccp.

Thanks
Peter

On 9/5/07, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>
> On 5-Sep-07, at 1:27 PM, Kris Jurka wrote:
>
> >
> >
> > On Wed, 5 Sep 2007, Josh Berkus wrote:
> >
> >>> Can't you use DBCP or some other open source statement cache
> >>> implementation that's in a more mature state?
> >>
> >> Unfortunately, no. The benchmark is already out.
> >>
> >
> > But that benchmark was run with a different caching implementation
> > than the wrapper version, so I'm not sure how that's relevant.
> > When Sun chose to use unpublished and unreviewed code for the
> > benchmark they got themselves in a little bind and I'm not sure
> > it's our job to bail them out by publishing and advertising code
> > that we're not confident in. Heikki, Oliver, and myself did not
> > believe the code used by Sun in the benchmark was correct in the
> > general case so it was rejected for inclusion in the core driver.
>
> So as I understand it the objection to the caching implementation is
> that statement caching belongs in the app server ?
>
> If this is the case then I would argue that having caching in the
> appserver is a great idea for everyone using an appserver it does not
> help the rest of the world that doesn't use an app server.
>
> Is there a technical argument here ?
>
> Dave
>
> > Dave/Lazlo have since started a new implemention on pgfoundry, but
> > that was never discussed with the JDBC list or submitted for
> > inclusion.
> >
> > To satisfy the benchmark requirements, Sun should publish the code/
> > driver actually used in the benchmark somewhere on Sun's website
> > and, if honest, should recommend that people don't use it. From
> > there we should try to gather some consensus on whether PG needs
> > its own statement cache implementation and then rerun the
> > benchmarks with it or some other implementation.
> >
> > Kris Jurka
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>