Re: Caching driver on pgFoundry?

From: Paul van den Bogaard <Paul(dot)Vandenbogaard(at)Sun(dot)COM>
To: Peter Kovacs <peter(dot)kovacs(dot)1(dot)0rc(at)gmail(dot)com>
Cc: Kris Jurka <books(at)ejurka(dot)com>, Dave Cramer <pg(at)fastcrypt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Caching driver on pgFoundry?
Date: 2007-09-06 09:20:49
Message-ID: 1B31C48C-6D28-4C30-968B-81BDA207060D@Sun.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

if the caching & pooling stuff is in the same jar file as the rest of
the JDBC driver than my point is empty. If it is (can be seen as) an
extra element that it is very likely it will mean extra work for the
Q&A department of the ISV.
Test suite is likely to become

on platform A, test with and test without
on platform B, test with and test without

continues till all platforms are covered.

In general one more element translates in more permutations.

--Paul

On 6-sep-2007, at 9:51, Peter Kovacs wrote:

>> Been working with different ISVs for almost 10
>> years now and every element they include in their suite will in
>> general be included in their Q&A tests. One more element of the suite
>> they support means many more tests. It makes it more difficult (this
>> to some extent might be perception, but it is something that does
>> matter to them) to do it so they will be more reluctant to support
>> it.
>
> ISV will not extra-test the driver(s) which comes with the database,
> will they? (I mean, they don't test driver's separately by default.)
> If you, for example, bundle the Commons DBCP with the JDBC driver,
> this argument becomes pretty much empty.
>
> Thanks
> Peter
>
> On 9/5/07, Paul van den Bogaard <Paul(dot)Vandenbogaard(at)sun(dot)com> wrote:
>> posted my ideas on august 9. seen no reaction. I think that's a yes
>> vote. Not sure if it counts though.
>> To restate:
>>
>> apps servers have statement caching build in because at the time it
>> was created there were (almost) no drivers out there implementing it.
>> Guess Suns driver is one of the few that does not have an
>> implementation.
>>
>> From an architectural point of view I feel a statement is part of a
>> connection. Therefore it belongs in a connections. However I do admit
>> there are many ways to implement this view.
>>
>> I know that adding an extra jar file will reduce its acceptance in
>> the ISV community. Been working with different ISVs for almost 10
>> years now and every element they include in their suite will in
>> general be included in their Q&A tests. One more element of the suite
>> they support means many more tests. It makes it more difficult (this
>> to some extent might be perception, but it is something that does
>> matter to them) to do it so they will be more reluctant to support
>> it.
>>
>> The wrapper is an extra layer that needs to be crossed while
>> "creating" a statement from the pool. However I doubt that it will
>> make a significant (negative) impact when compared to the all-in-one
>> approach. The real net effect of using statement caching is the
>> reduction of work on the database side.
>>
>> Finally it is not just appsservers out there. Lots if J2SE
>> application exist in at least the Telco segment. Would love to see
>> these guys to adopt a free database instead of Oracle that is all
>> over that place.
>>
>>
>> --Paul
>>
>>
>> On 5-sep-2007, at 20:25, Kris Jurka wrote:
>>
>>>
>>>
>>> On Wed, 5 Sep 2007, Dave Cramer wrote:
>>>
>>>> On 5-Sep-07, at 2:12 PM, Kris Jurka wrote:
>>>>
>>>>> You clearly believe we need this and I'm sort of on the fence (I
>>>>> recall that's where Oliver is as well, but I don't claim to speak
>>>>> for him).
>>>>
>>>> So we basically have one nay vote holding this up ?
>>>>
>>>
>>> But we only have one yes vote pushing it forward. At least of the
>>> four of us, I haven't gone back to the archives to see if anyone
>>> else weighed in on the discussion.
>>>
>>> Kris Jurka
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>>> choose an index scan if your joining column's datatypes do not
>>> match
>>
>> ---------------------------------------------------------------------
>> ---
>> ---------------------
>> Paul van den Bogaard
>> Paul(dot)vandenBogaard(at)sun(dot)com
>> CIE -- Collaboration and ISV Engineering, Opensource Engineering
>> group
>>
>> Sun Microsystems, Inc phone: +31
>> 334 515 918
>> Saturnus 1
>> extentsion: x (70)15918
>> 3824 ME Amersfoort mobile: +31
>> 651 913 354
>> The Netherlands
>> fax: +31 334 515 001
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>> choose an index scan if your joining column's datatypes do not
>> match
>>

------------------------------------------------------------------------
---------------------
Paul van den Bogaard
Paul(dot)vandenBogaard(at)sun(dot)com
CIE -- Collaboration and ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc phone: +31
334 515 918
Saturnus 1
extentsion: x (70)15918
3824 ME Amersfoort mobile: +31
651 913 354
The Netherlands
fax: +31 334 515 001

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Heikki Linnakangas 2007-09-06 09:26:25 Re: Caching driver on pgFoundry?
Previous Message Oliver Jowett 2007-09-06 09:14:21 Re: Caching driver on pgFoundry?