[I] Rationalize the usage of `Connection` in the JDBC appender (logging-log4j2)

["ppkarwasz (via GitHub)" <gi...@apache.org>]

ppkarwasz opened a new issue, #1916:
URL: https://github.com/apache/logging-log4j2/issues/1916

   The JDBC appender takes a very conservative approach to SQL connection sharing:
   
   1. as most appenders, each `append` call is synchronized,
   2. each event (or batch of events) is logged using a different `Connection` object, which is closed at the end of the call,
   3. to prevent the high performance hit from creating many `Connection`s, users are advised to use a connection pool like DBCP2.
   
   This approach has many disadvantages:
   
   - it does not profit from the connection pool, since at any time at **most** one connection will be borrowed from the pool,
   - on the other hand users that use `DriverManager` get a performance hit, even if 1. ensures that no `Connection` object will be used concurrently on multiple threads. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Rationalize the usage of `Connection` in the JDBC appender (logging-log4j2)

["ppkarwasz (via GitHub)" <gi...@apache.org>]

ppkarwasz commented on issue #1916:
URL: https://github.com/apache/logging-log4j2/issues/1916#issuecomment-2457901478

   > We already do sharing through the `log4j-jdbc-dbcp2` module. The default behavior should be as simple as possible IMO.
   
   I am OK with using **one** `Connection` per log event or batch, but in that case we should allow **multiple** `Connection`s to be used by multiple threads. Currently all database appenders have the same limitations that `OutputStream` appenders, with synchronization in `AbstractDatabaseManager.write()`:
   
   https://github.com/apache/logging-log4j2/blob/d229eda077c313a8a2060caa42531f6b539b1a09/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/AbstractDatabaseManager.java#L297-L303
   
   Currently this limitation is only due to the fact that `Connection` and `PreparedStatement` created in the `connectAndStart()` method are passed to `writeInternal` through **instance** fields of `JdbcDatabaseManager`:
   
   https://github.com/apache/logging-log4j2/blob/d229eda077c313a8a2060caa42531f6b539b1a09/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/db/AbstractDatabaseManager.java#L325-L332
   
   We can easily:
   
   - Use `ThreadLocal` in `2.x`.
   - Change the API in `3.x` to pass that context data as method parameters.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Rationalize the usage of `Connection` in the JDBC appender (logging-log4j2)

["garydgregory (via GitHub)" <gi...@apache.org>]

garydgregory commented on issue #1916:
URL: https://github.com/apache/logging-log4j2/issues/1916#issuecomment-2457165010

   We already do sharing through the `log4j-jdbc-dbcp2` module. The default behavior should be as simple as possible IMO. Or, we can bake in the use of Commons DBCP and always offer pooling through that. I don't think we should provide a _third_ behavior. Either you get the stock KISS behavior or you get pooling through Commons DBCP.
   
   To muddle the waters further, some JDBC Driver do their own connection pooling; I was the co-author of such a Driver.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org