RE: Questions about ADONetAppender (Resent with correct subject)

[Nicko Cadell <ni...@neoworks.com>]

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:cliff.burger@gmail.com] 
> 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 < cliff.burger@gmail.com 
> <ma...@gmail.com> >:
> 
> 	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. 
> 	
> 
> 
>