>Well, I'm not going to try to write the be-all and end-all JDBC-based >appender at this moment. My goal is to write a simple appender that >uses PreparedStatements over straight Statements. Another goal is ease >of configuration. > >Frankly, I don't think that implementing batch updates into the appender >is the way to go. A better batch strategy in my mind is to have some >sort of queueing appender that queues the events asynchronously to a >listener. The listener can handle the batches however it wants. (JMS >would be a good choice here.) That way you avoid having some calls take >significantly longer than others and you push the threading issue to >where it can be handled gracefully.
I also thought about this approach - essentially sending the log request to some other machine and allowing that machine to log to the db. This approach won't slow down the clients much. You don't have to write the be-all yourself, but if your architecture/design allows people to plug in the functionality that they desire for when and how to log to the database, then everybody wins. Here at work we interact with the database via stored procedures for everything we do (a whole lot of extra code IMHO, but it allows us to have a single point of entry to the database which helps maintain sanity on 400 table databases). We would be more interested in a CallableStatement approach than a PreparedStatement approach. If there is a way for me to write a CallableStatement "plugin" to use with the JDBCAppender instead of the default PreparedStatement one, then that'd be cool too. Just as long as the design allows for it. Thanks! Richard [EMAIL PROTECTED] wrote: > Wow! The list was boring there for a few days -- that's over :-) How > exciting. > > Anyway, I wrote a quick and dirty JDBC appender for work. We also had a > buffer that filled with logging requests and when it reached a certain > threshold, it would do a batch update to the database from a separate > thread. > We didn't have to worry about it being used in an EJB container, > so it was really a good idea. It is my understanding that batch updates > are faster/more efficient than executing a lot of single requests. > Especially if those requests are not prepared statements or callable > statements! The plan here is to use PreparedStatements. > > Other problems I faced: > > 1) The user logs into the application. If logging statements prior to > this point are made and should go to the database - what username password > do they use? The appender needs to have that info separate from the app. > 2) If we reach the end of the program and we use a buffer - how do we put > those statements into the database? Explicit call - no. Had to use a > finalize method. That may be an instance of when it is appropriate to use > a finalize - but only if the appender forms a separate connection to the > database. A shutdown hook would have been a better choice (assumes a high enough JDK). > > Some applications may have a limit on database connections and don't want > to have a whole db connection used up by the logging subsystem whereas > others are more concerned about speed via batch updates and still others > would be concerned about using a stored proc so they could do other things > with the data on the database side....and so forth. > That said, my perspective is more from the server/J2EE side than the client side, so perhaps that is coloring my conclusions. Ray
