Cliff, The AdoNetAppender is designed to be a generic configurable appender for writing to any ADO database. If you have a specific database in mind you may be better served building a custom appender. Especially if you have a fixed database schema in mind.
There is an simple example database appender in the log4net download: examples\net\1.0\Appenders\SampleAppendersApp\cs\src\Appender\FastDbAppe nder.cs You can customise this to build the appender to your requirements. Cheers, Nicko > -----Original Message----- > From: Cliff Burger [mailto:[EMAIL PROTECTED] > Sent: 21 June 2006 18:58 > To: Log4NET Dev > Subject: Questions about ADONetAppender (Resent with correct subject) > > Sorry ... I just realized I sent under the thread "log4net > 1.2.10 Released" which would cause some confusion. > > > 2006/6/21, Cliff Burger < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> >: > > Questions about ADONetAppender > > I'm considering creating a MSSQLAppender for my > company's use, as we are primarily an MS Shop. General questions: > > Is anyone else already working on this? > Are the issues I'm addressing valid? > Should some of the changes I want to make be promoted > into the general purpose ADONetAppender? > > Save cost of reflected object creation. > The ADONEt appender appears to create a > System.Data.SqlClient.SqlConnection object via reflection > each time it sends the buffer. In my experience, reflection > is a little slow. Given that we use this in non-lossy mode, > it must create a connection using reflection every time a > message is sent. Avoiding this cost requires a MSSQLAppender > in the current implementation. Are my assumptions about the > performance of the Activator correct or incorrect? > > Another option that would work in a ADONETAppender case > is to create the connection object and leave the instance > around, using Open / Close rather than dispose. Object would > be disposed would only in "OnClose". Rathering than incurring > costs of creating an object via reflection for each message, > we only incur the cost once, during the creation of the > Appender. Does this run the risk that configurations are > changed during a running program, and not picked up by the > appender, or is the appender instance recreated in this case? > > Connection behavior: > ADONetAppender currently creates a new connection > object and opens it each time a buffer is sent. It holds onto > the instance and open connection until 1) the logger is > "Closed" or 2) A message is sent. It has a somewhat silly > behavior of closing and reopening the connection right before > sending the message - but not closing it after the message is > sent. We don't get the benefit of avoiding cost of re-opening > a connection, but also don't get the benefit of keeping > connections closed when not in use. > > Option a: The most performant behavior for unpooled > connections would be: Keep the connection object open until > the logger is closed. Before a message is sent, check that > the connection is open ... but don't reopen if a connection > object is present and open. This (like the current behavior) > is slightly un-safe if transactions are used ... I've > previously had problems with this appender leaving > uncommitted transactions and locking tables. > > Option B: The most sensible behavior for pooled > connections (and safest) would be: Open connection, send > buffered messages, and close the connection. This gives fine > performance with pooled connections where connection isn't > really reopened/ closed, it's just returned to the pool. This > would incur a performance costs in non-pooled connections, > but is no different from current behavior. Closing the > connection ensures that any hanging transactions are > committed or rolled back. > > The safe behavior is to use option B - this is also the > behavior which will make our DBA happiest. The best solution > might be to control the behavior of connections via > configuration to optimize for pooled / nonpooled scenarios - > but I probably won't take the time for this in my extension > of this appender. > > Transaction behavior: > When transactions are used with this appender, it > sometimes results in locking the log table - the transactions > were left hanging uncommitted. The default behavior is to use > transactions. I haven't had time to determine exactly what > causes the problem. Given that the risk exists, and when it > occurs the consequences are severe (can't do anything at all > with the log table), I'd like to set the default behavior to > NOT use transactions. > > > >
