Hi Gary, On Mon, 16 Oct 2023 at 23:45, Gary Gregory <garydgreg...@gmail.com> wrote: > > 4. The appender itself is quite wasteful in the number of connections > > it uses (one per log message). IIRC JDBC connections are not > > thread-safe, but can be used from multiple threads if synchronization > > is provided. `AbstractDatabaseManager#write` provides such a > > synchronization. With the current connection usage pattern, the > > "DriverManager" connection source is basically useless. > > 5. We should consider integrating the JDBC pooling features with PR > > 1401: https://github.com/apache/logging-log4j2/pull/1401. > > Pooling is already supported by the jdbc-dbcp2 module. > What am I missing?
Regarding 4: I think that the current solution is suboptimal for both DriverManager and DBCP2 users. DBCP2 users have a wonderful connection pool, but due to double synchronization (in `AbstractDatabaseAppender#append` and `AbstractDatabaseManager#write`), they only use a single connection at each time. DriverManager could be good choice for an asynchronous appender/logger: it just needs to create a connection at startup and release it when the application is shut down. However, due to the way connections are used right now each log event or batch of events incurs in the overhead of creating a DB connection. Regarding 5: I haven't figured out how `StringBuilder` caching/pooling relates to `Connection` caching/pooling, but I think it is a direction worth exploring. I am aware that DBCP2 is more than Commons Pool 2 + DriverManager, so the JDBC appender itself will probably not profit from the `Recycler` interface, but other database appenders might. I have never user NoSQL databases, but I don't believe they all offer thread-safe clients with an integrated connection pool. 6. Another improvement that we could add to the JDBC appender is buffering the log events using `PreparedStatement#addBatch` instead of taking memento's of events and appending them to a list. Piotr
