Re: Fwd: Caching driver on pgFoundry?

László Hornyák wrote:
> 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

As far as I can see, there's nothing in the spec that you can't
implement in a generic wrapper. The methods added in JDBC4 allow the
application to explicitly ask the connection pool/statement cache to not
cache a statement. Implementation of that feature is exactly the same,
whether the statement cache comes with the driver, the application
server, or as a separate module.

> - 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.

Nothing stops you from using the caching wrapper with the DriverManager
interface. I believe DBCP supports that as well.

> 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.

Frankly I don't understand what the benefit of a combined jar is. Surely
if you can add one jar to your classpath, you can add two. But I won't
object if someone wants to maintain such a combined jar; it's not going
to harm me or anyone else that such a thing exists, as long as you're
not forced to use it.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com