logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Sandee <tbsan...@pobox.com>
Subject Re: Log4j JDBCAppender
Date Thu, 06 Jun 2002 18:07:57 GMT
Kevin Steppe wrote:

> The double quote should fix #2.  Any time you are putting a string 
> into a varchar type field you should use either single or double 
> quotes. Without quotes you'll have all sorts of errors.  As for 
> performance successful statements will always go faster than failed 
> statements :)
>
> The preparedStatement option seems nice in theory but I believe 
> doesn't merit the work: 
> 1) The configuration would need to be more complicated to properly 
> handle the variety of types/values/etc you might want to set.
> 2) Escaping is still a problem, b/c the appender has to handle any 
> number of quotes in a general fashion (unlike your example where you 
> know exactly how many and where the quotes are)
> 3) The performance value of preparedStatements is debate-able.
> 4) Batch inserts make far more difference and will be included very 
> soon (it's being tested)
> 5) stored procs will work the current appender which is the same or 
> better than preparedStatements anyway
>
> Stored Procedure example (works with MS-SQL, not tested on Oracle)
>
> sql= myLoggingSproc "%c", "%t", "%p"
>
> Kevin


Kevin,

I agree it's not worth the effort -- primarily because for my projects I 
don't want log data stored in a database anyway -- and I work at a 
company historically known for it's database software! :-) (Sybase)

I do take issue with two of your statements, #2 and #3 in particular.

#2, I don't see how escaping is still a problem -- with string columns 
you can simply pass any data into the parameter without escaping at all. 
 You don't need to know anything about the contents or the target 
database server.

#3, this performance opinion of prepared statements is very 
implementation dependant.  I'm not sure what exactly is giving you 
negative feelings towards the PreparedStatement object, but realize that 
the performance levels vary widely by driver -- the PreparedStatement 
implementation often gets the shaft when it comes to optimization time, 
I fear.  For the JDBC driver produced by my employer, prepared 
statements and normal statements have effectively the same performance 
level -- it doesn't really matter how you are passing the parameters. 
 With our JDBC driver, it isn't actually preparing the statement and 
caching the query plan on the server unless you enable a flag in the 
JDBC driver to explicitly do server-side statement preparing.  If this 
is done, performance can vary widely depending on whether or not the 
statements actually get re-used or not.  Many times it goes down, 
sometimes, if there is much statement reuse it will go up.

Unfortunately the JDBC spec leaves out the possiblity of a parameterized 
"unprepared statement" for those times when I have a query that I don't 
plan on re-using.  It really is almost obscene that we ever need to 
resort to generating queries by concatenating strings, as advanced as 
other pieces of the Java API's have become... <shrug> :-)

Ben





--
To unsubscribe, e-mail:   <mailto:log4j-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-user-help@jakarta.apache.org>


Mime
View raw message