Another thing to consider is how this would look from a configuration POV. It would be nice to avoid code for most of it. I suppose that's what JNDI is for but you still have to populate the store.
Gary -------- Original message -------- From: Nick Williams <nicho...@nicholaswilliams.net> Date:02/05/2014 17:46 (GMT-05:00) To: Log4J Developers List <log4j-dev@logging.apache.org> Subject: About the DriverManagerConnectionSource Guys, Currently, the JDBCAppender allows users to specify a mechanism for connecting to the database using one of three options: - DataSourceConnectionSource: Looks up a JNDI data source - FactoryMethodConnectionSource: User specifies a class and static method for retrieving connections - DriverManagerConnectionSource: User specifies JDBC URL, username, password, etc. to manually connect directly from Log4j. Here's the problem: connections really need to be pooled for Log4j to log efficiently. In fact, I'd go so far as to say it's a *requirement*. It will either be flaky (if using the same connection continuously) or horrendously slow (if reconnecting every time) without pooling. DataSourceConnectionSource and FactoryMethodConnectionSource lend themselves naturally to pooling. We can simply tell the user, 1) the DataSource must be a pooled DataSource or performance will suffer greatly, and 2) The factory must be backed by a connection pool or performance will suffer greatly. At that point, it's out of our hands and left up to the user to pool it. I like this. DriverManagerConnectionSource is a different story. Since Log4j connects directly using this approach, we're left with two options: - Remove support for DriverManagerConnectionSource and force the user to supply a factory or DataSource. (This is my favorite option.) - Add Commons DBCP and Commons Pooling as required dependencies when using DriverManagerConnectionSource, then update DriverManagerConnectionSource to also accept connection pool size, thresholds, maximums, minimums, test queries, etc. (I really, *REALLY* don't like this option.) I'm looking for some input from the rest of y'all on which direction we should take, or if you can think of any other options. Thanks, Nick --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
