Re: statement caching patch from Laszlo Hornyak for review

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.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 2: Don't 'kill -9' the postmaster