Is SLF4J good to be used in a multithreaded application for logging to a database?

Question

I am working on a multithreaded application. I am already using Log4j to log statements to files.
I have been recently looking into the possibility of logging to a Mysql database.

The logging component has to be reliable under a heavy load and has to be thread safe.
I heard of SFL4J. My understanding of SLF4J is that is just a facade or abstraction layer.

• I was wondering if SLF4J was a good database logging solution to use in a multithreaded application?
  
  
• And in the case of a heavy load, would it be a good idea to add a layer (like a buffer or a queue) and let the threads log to it instead of calling the logging thread directly (The logging thread would send the statements found in the queue one by one to the database)?

Any tips, best practices or code example would greatly be appreciated,
Regards,

Answer 1

You're right that SFL4J is just a facade, it allows writers of libraries and frameworks to do their logging through the facade and have the application specify its own logging framework. At the application level there's not as compelling a reason to use SLF4J, you might as well use log4j directly. The only benefit would be that you could swap over to logback at a future date with less changes. That's not all that compelling, unless you have a case where you are uncertain which logging implementation you want to go with, in which case you could use the abstraction layer so that you could swap out implementations in comparison tests.

Using SLF4j won't affect concurrency. You might want to consider different appenders (or roll your own) for the actual logger, it wouldn't affect how you called SLF4J though. The only place where concurrency would be impacted is in the appender.