Re: statement caching patch from Laszlo Hornyak for review

Hi!

A short summary of the wrapper/patch-the-core question, feel free to extend
it.

Advantages of the prepared statement caching feature coded into the JDBC
Driver:
- Better performance for preparedstatements if the connection is established
with DriverManager or the pg DataSource implementation. I will post some
benchmark result...
- Easy to configure: the pg jdbc jar on the classpath and some parameters
appended to the URL
Disadvantages:
- Lot of code compared to relatively few users (still a lot imo)

Advantages of a wrapping solution:
- Completely external project, helps to keep the driver codebase small
- Does not add much overhead on the client side, still good performance
- Works with other JDBC Drivers (not much value if most JDBC Driver does
this feature)
Disadvantages:
- Somewhat more work to setup (still worth the little work imo): pg jdbc jar
file plus wrapper jar file and pg JDBC URL prefixed by the wrapper URL and
parameters (e.g.
jdbc:wrapper[preparedStatementPoolSize=64;otherParam=blabla]:postgresql://localhost/DB,
feel free to suggest a more friendly look)
- As external project, it is just one more thing for the programmers to keep
an eye on

Now, with the input from the mailing list, a wrapper solution is under
development, since I do not have to work with a lot of existing code in this
case, you can expect it soon.
Your input is welcome!

On 09/08/07, Paul van den Bogaard <Paul(dot)Vandenbogaard(at)sun(dot)com> wrote:
>
> Hi,
>
> I am quite new in the PostgreSQL arena. However I know there are
> drivers that do implement SC (Oracle, mySQL, third party drivers for
> DB2). I believe the application servers have this build in out of
> pure necessity: when they needed it there simply were no drivers
> available that offered this. Therefore the motivation "most of them
> have it, so why should we offer it" sounds not too motivational to me.
>
> I believe that since a statement is part of a connection the proper
> place for a pool is within that connection (to me at least from an
> architectural/design point of view). I feel any self respecting
> driver should offer SC. Of course in a way that can also be used by
> applications that have no need for it. Either because they know each/
> most statements are a one time thing or for other reasons. Of-course
> in a safe way, although I am not sure a wrapping object is the only
> way to ensure this. This however is an discussion of implementation.
>
> Why do I dare to make this bold statement?
>
> First there are many more applications out there that use a database
> but are not J2EE. Therefore these would not benefit from SC build
> into application servers.
> Second all the ISVs I have been working with (the majority in the
> finance, erp, crm, telco segments) use a (transactional)database.
> Some of them are using non prepared statements. Most of them are
> using or planning to use prepared statements. All these ISVs use
> Oracle and the Oracle JDBC driver (I only did meet one that also
> offered a home made Oracle driver). They all use the SC feature.
> Third these ISVs have so much work to do in their build,test,release
> cycle that they will not easily accept another database. Let alone a
> database that mandates the use of yet another element (the SC
> wrapper) to get a feature they do need.
> Fourth, the code they need to maintain is already so large that they
> do not want to implement a SC feature themselves.
>
> Hopefully these practical reasons are also taken into consideration
> in the discussion if SC needs to be(come) part of the core.
>
> Regards,
> Paul
>
> ------------------------------------------------------------------------
> ---------------------
> 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 2: Don't 'kill -9' the postmaster
>

--
László Hornyák