On Fri, Aug 15, 2003 at 04:22:17PM +0100, Paul Thomas wrote:
> a) making them work with connection pools. Currently (as in released not
> CVS tip) the server-side statement is deallocated when the JDBC statement
> is closed. I was looking at this a few weeks ago whilst experimenting with
> server-side prepares. Somehow, the back-end statement names need to be
> cached so the statements can remain "alive" after the JDBC statement has
> been closed (and also deallcated when connections are closed).
This should be done in the pooling implementation, not in the driver. (well,
modulo the JDBC3 statement caching bits, which I haven't looked at). You can
do this in a driver-independent way: wrap prepared statements and have
close() return the underlying statement to a per-connection cache rather
than closing the underlying statement. Somewhat like connection pooling,
really: the pooling mechanism manages the creation and destruction of the
underlying driver resource according to whatever rules it implements. The
driver doesn't need to do anything clever and just implements the
create/destroy/use primitives.
> >The reason that this came up is I'm modifying the driver to allow
> >server-side prepare to be toggled at the connection- and datasource-
> >level.
> >Patches for that to follow once I've sorted this problem out.
>
> Does that include having a parameter in the URL? Some people might find
> that very useful as they could then use server-side prepares without
> having to import any postgres-specific classes and for connection pooling,
> I think it would be essential.
A URL parameter would be easy to add. We use reflection on DataSource
javabean-like methods to get the same sort of driver independence here.
-O
