Re: Caching driver on pgFoundry? - Mailing list pgsql-jdbc
From | Paul van den Bogaard |
---|---|
Subject | Re: Caching driver on pgFoundry? |
Date | |
Msg-id | 1B31C48C-6D28-4C30-968B-81BDA207060D@Sun.COM Whole thread Raw |
In response to | Re: Caching driver on pgFoundry? ("Peter Kovacs" <peter.kovacs.1.0rc@gmail.com>) |
Responses |
Re: Caching driver on pgFoundry?
|
List | 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.Vandenbogaard@sun.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.vandenBogaard@sun.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.vandenBogaard@sun.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
pgsql-jdbc by date: