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.
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.
That said, my perspective is more from the server/J2EE side than the client side, so perhaps that is coloring my conclusions.
Ray
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
