Re: statement caching patch from Laszlo Hornyak for review - Mailing list pgsql-jdbc
| From | László Hornyák |
|---|---|
| Subject | Re: statement caching patch from Laszlo Hornyak for review |
| Date | |
| Msg-id | 809bf8d30708100104r1d5de68ey8d553173090874a1@mail.gmail.com Whole thread Raw |
| In response to | Re: statement caching patch from Laszlo Hornyak for review (Paul van den Bogaard <Paul.Vandenbogaard@Sun.COM>) |
| Responses |
Re: statement caching patch from Laszlo Hornyak for review
|
| List | 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!
--
László Hornyák
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.Vandenbogaard@sun.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.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
--
László Hornyák
pgsql-jdbc by date: