On Tue, 10 Sep 2002, Barry Lind wrote:
> Yes I can check the server version on connect. In fact that is what the
> driver already does. However I can't check the version and then based
> on the version call set autocommit true in one round trip to the server.
> Since many people don't use connection pools, I am reluctant to add
> the overhead of an extra roundtrip to the database to set a variable
> that for most people will already be set to true. It would be ideal if
> I could in one hit to the database determine the server version and
> conditionally call set autocommit based on the version at the same time.
Hmm. I don't think that there's any real way to avoid a second round
trip now, but one thing we might do with 7.3 would be to add a standard
stored procedure that will deal with setting appropriate variables and
suchlike, and returning the version number and any other information
that the JDBC driver needs. (Maybe it can return a key/value table.)
That way, once we desupport 7.2 in the far future, we can reduce this to
one round trip.
Or perhaps we we could try to execute that stored procedure and, if it
fails, create it. (Or, if creating it fails, do things the hard way.) That
way the first connection you make where the SP is not there you have the
overhead of adding it, but all connections after that can use it. (I assume
you'd grant all rights to it to the general public.) And it could return
its own version so that newer drivers could upgrade it if necessary. Or
maybe just have a differently-named one for each version of the driver.
This is a bit kludgy, but also sort of elegant, if you think about it....
On the other hand, perhaps we should just live with two round trips. So
long as we've got command batching at some point, we can get the version,
and then send all the setup commands we need as a single batch after that.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
