Skip site navigation (1) Skip section navigation (2)

Re: statement caching patch from Laszlo Hornyak for review

From: László Hornyák <kocka(dot)public(at)gmail(dot)com>
To: "Paul van den Bogaard" <Paul(dot)Vandenbogaard(at)sun(dot)com>
Cc: "Oliver Jowett" <oliver(at)opencloud(dot)com>, "Dave Cramer" <pg(at)fastcrypt(dot)com>, "Kris Jurka" <books(at)ejurka(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: statement caching patch from Laszlo Hornyak for review
Date: 2007-08-10 08:04:39
Message-ID: 809bf8d30708100104r1d5de68ey8d553173090874a1@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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

In response to

Responses

pgsql-jdbc by date

Next:From: Andrea SpinelliDate: 2007-08-10 08:24:22
Subject: executeQuery hangs on busy server - PROPOSAL: socketTimeout parameter
Previous:From: Paul van den BogaardDate: 2007-08-09 15:44:45
Subject: Re: statement caching patch from Laszlo Hornyak for review

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group