Sorry, I wanted to send this to the list...
---------- Forwarded message ----------
From: László Hornyák <kocka.public@gmail.com >
Date: 07-Sep-2007 15:55
Subject: Re: [JDBC] Caching driver on pgFoundry?
To: Oliver Jowett <oliver@opencloud.com>
Hi!
On 07/09/07, Oliver Jowett <oliver@opencloud.com > wrote:
What is the implementation advantage of making statement pooling part of
the main driver? There are maintenance issues which count *against* it
being part of the driver so you need to provide a good reason to include it.
There are two main reasons I can mention:
- JDBC 4 allows prepared statement pooling (Which is optional, the driver can ignore the programs request to cache the prepared statement, and I believe it enables some kind of early optimization for those who like to do early optimizations. But that is just my opinion, but JDBC 4 specification expects drivers to deal with it. Time will tell, maybe data access layers like hibernate or JPA implementations in the future will use it) see
http://java.sun.com/javase/6/docs/api/java/sql/Statement.html#setPoolable%28boolean%29 - Clients that do not use DataSource, but only DriverManager can gain significant speed improvement. Now, you get prepapred statement caching if the wrapper ( e.g. DBCP) gives it, not if you use a pg connection directly.
Packaging issues are IMO fairly irrelevant because if you must give a
single package to your users, you can always take the base driver and a
separate pooling wrapper, package them together, and say "Hey look here
is the statement-pooling postgresql JDBC driver".
Yes, any developer can do that, but it would probably save some time for developers if they wouldn't have to.
-O
---------------------------(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
--
László Hornyák --
László Hornyák
