I think if we added a DBCP/CP dependency version, that should be a separate or optional module/plugin. It seems like it'd be useful as a demonstration for a connection source factory.
On 5 February 2014 16:46, Nick Williams <nicho...@nicholaswilliams.net>wrote: > 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 > > -- Matt Sicker <boa...@gmail.com>
