The value I'm expecting from using this appender is the ability to use where clause to filter log events instead of custom filters, which will effect performance. I don't know about you but I find it easier to search through a db table than a log file.
However, if the appender doesn't support this, then I guess the alternative is to use the JMSAppender. This seems to be a (debateably) preferred approach to logging anyway. ----------- OFF TOPIC: ----------- Is the oracle jdbc driver's PreparedStatement implementation higher performing than a non prepared statement? -----Original Message----- From: Ben Sandee [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 11:08 AM To: Log4J Users List Subject: Re: Log4j JDBCAppender 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
