On Apr 13, 2004, at 5:18 PM, Oliver Jowett wrote:
> This sounds like JDBC3's "statement pooling" option. There's no API
> for this, it's just allowable behaviour, so we should be fine to
> implement something like this.
Diving in, I see that Postgres's PREPARE statement needs the types
up-front, as in:
PREPARE t_prep (TEXT) as select id from users where name = $1;
But PreparedStatement doesn't know the JDBC datatypes (which we map onto
Postgres types) until execute time. Hence I guess
AbstractJDBC1Statement's
delaying of server-preparing until execute-time, when all of the params
have
been pushed in.
A global cache of prepared PreparedStatements seems to have to assume
that
subsequent calls ought to be executed with the same param types. Is
this too
bold of an assumption -- I know that in my EJB code this will hold, but
I don't
know about others.
Unless the key to the map of cached prepared statement also
incorporates the
type signatures of each param. Ugh. That would push fetching from the
map
until the actual executeQuery() call on PreparedStatement, as opposed to
at Connection.prepareStatement(String queryPattern) time -- which I
can semi-gracefully hook into in AbstractJdbc3Connection.java to
keep JDBC1/2 unaffected. The executeQuery() hooking looks harder to
implement without poisoning JDBC 1/2.
Unrelated, what is the philosophy regarding putting what type of code in
the AbstractXXX class as opposed to the JDBCNXXX class? I'm sure there's
a good reason, but it escapes my grasp at the moment ...
----
James Robinson
Socialserve.com