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@optc.com | -- Edna St. Vincent Millay

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.

If your proposal it so use log4j for logging, then I would be opposed.
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.

thanks,
--Barry

btoback@mac.com wrote:

Hi all,

One more question/comment.

In order to track down the problem with the interaction between
WebObjects and the PostgreSQL JDBC driver, I had to insert a fair
amount of logging. This logging will be useful for anyone else who's
in a similar position, trying to get some piece of middleware to work
with PostgreSQL. If I switch to using log4j (see
http://jakarta.apache.org/log4j for information), would it be useful
to submit the logging calls as a patch?

I think it would be extremely useful, but I don't know the
philosophies or mindset of the PostgreSQL developers, so I thought I'd
ask.

-- 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@optc.com | -- Edna St. Vincent Millay

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Bruce,

I agree that log4j is probably overkill. I also understand the need for
better logging. I have been fortunate that I can run through a debugger
so that I have been able to track down any problems I have had when the
server sql statment log isn't sufficient.

The one good thing about postgresql (unlike other databases I use) is
that at least you have access to the source code so that you can add
prints as needed.

thanks,
--Barry

Bruce Toback wrote:

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@optc.com | -- Edna St. Vincent Millay

btoback@mac.com wrote:

Hi all,

One more question/comment.

In order to track down the problem with the interaction between
WebObjects and the PostgreSQL JDBC driver, I had to insert a fair
amount of logging. This logging will be useful for anyone else who's
in a similar position, trying to get some piece of middleware to work
with PostgreSQL. If I switch to using log4j (see
http://jakarta.apache.org/log4j for information), would it be useful
to submit the logging calls as a patch?

I think it would be extremely useful, but I don't know the
philosophies or mindset of the PostgreSQL developers, so I thought
I'd ask.

-- 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@optc.com | -- Edna St. Vincent Millay

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Bruce Toback wrote:

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@optc.com | -- Edna St. Vincent Millay