Re: Caching driver on pgFoundry?

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