Version: log4net 1.2.9.0 platform: Windows 2000, MS SQL 2000 as target for appender. Logging from a web service (ASP 5.0)
BASIC PROBLEM: ADONetAppender uses transactions by default. Various conditions can leave these uncommitted. QUESTION: Does this problem qualify as a bug? We've turned off transactions in the ADONet appender. Any thoughts about other ways to prevent uncommitted transactions? RECOMMENDATION to users of ADONetAppender against a SQL server: Make sure transactions are OFF. Configuration file entry: <UseTransactions value="False" /> I'm going to rebuild the ADONetAppender for my company, with transactions off by default. I can't think of a good reason to keep them on. I send "EMERGENCY" level messages to someone else's pager via SMTP. DETAILS We've been using the apache logger extensively in the development of a new three tier product (web deployed rich client front end. Web service on IIS 5.0 in the middle. MS SQL 2000 on the back). We point the ADONETAppender at a reasonably straightforward insert stored procedure. Both the service and the front end log. The service logs as a special SQL auth logging user (so we know it's the service) and the front end logs with integrated security as the user using the application. Note that for testing and development purposes, I've loved the logger. During release candidate testing, the logger finally got a decent amount of use (about 2000 messages logged before it blew up). Within a few hours, the logger ended up locking the logging table, due to an uncommited transaction. I couldn't find an obvious code path in the ADONetAppender that could result in this condition, so here is the most probably explanation: While the appender.SendBuffer method wraps the transaction code in a Try / Catch, there are a variety of scenarios in ASP.NET where code exits without executing Catch or Finally code. This is explained in the MSDN article "Keep Your Code Running with the Reliability Features of the .NET Framework" at http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/default.aspx Note that I haven't found any other .NET 1.x documentation that admits that this can occur. At any rate, no commit or rollback code was called, and the logger left a transaction uncommitted on the database. Thanks, Cliff Burger
