Re: Caching driver on pgFoundry? - Mailing list pgsql-jdbc

>
> On 7-Sep-07, at 9:13 AM, Oliver Jowett wrote:
>
> > Dave Cramer wrote:
> >
> >> After a quick survey I couldn't find another non-GPL open
> source app
> >> server.
> >
> > Isn't that a fairly arbitary categorization to make? How about open
> > source app servers that don't begin with 'B'? ;-)
>
> It's not arbitrary at all. see below
> >
> > Seriously, not sure exactly what point you're trying to make here.
> > Why exactly should the existance and licensing of 3rd party
> software
> > affect technical decisions about the postgresql JDBC driver?
> >
> Companies are fairly careful when choosing components to put
> in their stack. GPL licensed products are considered to be
> business non- friendly. I was responding to Simon's
> suggestion that they could have used any other app server
> which did implement statement caching.
>

As a "satisfied" postgresql jdbc user and someone who works with a couple of
open source appservers I think its fair to point out that while GPL is
considered by many to be "non business friendly", many businesses are happy
with the LGPL licence.

Jboss is released under the LGPL and the jboss connection pool does include
statement caching (ie, the pool remembers which statements have been
prepared against which connections - which is my understanding of the
purpose of this thread).

So, if you are looking for an open source java/jee with postgresql option
that includes connection pool level caching of prepared statements then
there is already at least one option out there.

My own view is that I'd be suspicious of including connection level caching
in the same package as the standard JDBC driver if:

1) the pooling code slows down the standard driver when the pooling isn't
used

2) the release cycle of the pooling code "hobbles" the release of the main
driver

3) the pooling code breaks existing external pooling/caching options

Anyway, that’s my £0.02 - thanks for all the good work :)

Cheers,

Andy

> > I think we're drifting away from the main point which is,
> as I see it,
> > fairly simple:
> >
> > What is the implementation advantage of making statement
> pooling part
> > of the main driver? There are maintenance issues which count
> > *against* it being part of the driver so you need to provide a good
> > reason to include it.
> >
> Well, it has to be maintained regardless of where it is. So
> how does that make any difference ?
>
> > Packaging issues are IMO fairly irrelevant because if you
> must give a
> > single package to your users, you can always take the base
> driver and
> > a separate pooling wrapper, package them together, and say
> "Hey look
> > here is the statement-pooling postgresql JDBC driver".
>
> Dave
> >
> > -O
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>