Re: Caching driver on pgFoundry?

On Wed, 2007-09-05 at 21:20 +0100, Heikki Linnakangas wrote:
> Kris Jurka wrote:
> > On Wed, 5 Sep 2007, Dave Cramer wrote:
> >> 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.
> >
> > This is the consensus I'd like to see built before we spend a lot of
> > time on something. Heikki doesn't believe we should do this at all as
> > it is covered by DBCP and app server pools.
>
> To be clear, I think it's nice to have one more statement cache
> implementation around, with friendly BSD license. I encourage you to
> keep working on it, regardless of how this discussion ends.
>
> But let's not bundle it with the PostgreSQL JDBC driver, it's clearly a
> separate component. For applications that already have another
> connection pool / statement cache implementation, it would be just extra
> baggage. And as a separate project, you can use it with other DBMSs as
> well. Or bundle it with an app server :).
>
> Another point of view is to think about the release cycles of the JDBC
> driver and the caching wrapper. If a bug is found in the wrapper, and
> it's bundled with the JDBC driver, we would have to release a new
> version of the bundle, forcing an upgrade of both components even if you
> only use one. If we add a new feature to the wrapper, is that going to
> be backpatched to say the 8.1 branch? What if you're running 8.1 server
> and driver, and you want to take advantage of a new wrapper feature?
>
> The wrapper has enough merit to live a happy and successful life as a
> project of its own. I don't care if it's a separate pgfoundry project,
> or just a separate CVS directory within jdbc project and separate
> builds; the main point is that it should be a separate jar file with a
> separate release cycle. If we add a link to the latest version of the
> wrapper jar from jdbc.postgresql.org download page, people will find it
> regardless of where the development happens.

This sounds like the right approach to me.

We need to ensure Postgres works with everything and everybody. We do
want to help Blowfish, but not at an expense for other app servers.

Sun chose to use Blowfish, but could have chosen others for the
benchmark. We shouldn't go down a route with the software that is driven
because of an external, unrelated decision.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com