Re: Instrumenting and Logging in JDBC

On Sunday, June 24, 2001, at 09:49 PM, Barry Lind wrote:

> First I would ask what kind of logging you are talking about?
> I find that simply turning on debug output on the server to
> print out the sql statements being executed is generally all I
> need for logging, and the server already supports that.

The problem is that the SQL sent to the backend is sometimes the
end product of a lot of interaction between the JDBC driver and
the client program. This is frequently the case with
general-purpose programs like report writers and application
servers.

If the generated SQL is bad, or if the data the client program
receives back is bad, it's necessary to figure out exactly what
the client program is doing in order to solve the problem. For
example, the client may use some kinds of row metadata and not
others, or may be using an unusual sequence of calls to place
data into a PreparedStatement. Logging is the only way to figure
out what the client is doing if you don't have the client source.

> While logging is a good idea, having yet another non-postgresql
> component that needs to be installed in order to build and/or
> run the jdbc driver is in my opionion a bad idea. I already
> dislike the fact that I have to install ant just to build the
> driver. It was so much easier under 7.0 when make was all that
> was required.

Agreed -- especially given what it takes to get a Java program
to work, since there are no standards for where the various
components should live. Making ant work wasn't a pleasant
experience: it took more effort to build the 7.1 JDBC driver
alone than to build the entire 7.0 Postgres suite.

On the other hand, logging *is* useful in making sure that the
JDBC driver works with the widest possible variety of client
software, including all kinds of proprietary middleware
products. If the logging is set up so that log4j is loaded
dynamically, would that be a satisfactory solution to the build
problem?

Actually, given the purpose for including logging, log4j is
probably more than what's required to do the job -- essentially
just tracing client call activity.

-- Bruce

--------------------------------------------------------------------------
Bruce Toback Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc. (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142 | But ah, my foes, and oh, my
friends -
Phoenix AZ 85028 | It gives a lovely light.
btoback(at)optc(dot)com | -- Edna St. Vincent Millay