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

On 7-Sep-07, at 5:17 AM, Simon Riggs wrote:

> 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.

How does the architecture of the driver hinder 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.

After a quick survey I couldn't find another non-GPL open source app
server.

Dave