Fwd: Caching driver on pgFoundry?

Sorry, I wanted to send this to the list...

---------- Forwarded message ----------
From: László Hornyák <kocka(dot)public(at)gmail(dot)com>
Date: 07-Sep-2007 15:55
Subject: Re: [JDBC] Caching driver on pgFoundry?
To: Oliver Jowett <oliver(at)opencloud(dot)com>

Hi!

On 07/09/07, Oliver Jowett <oliver(at)opencloud(dot)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