Logging and TransactionScope

Topics: Logging Application Block
Aug 11, 2010 at 2:49 PM
Edited Aug 11, 2010 at 3:20 PM

We are using Enterprise Library 5.0 including the exception and logging blocks. We have run into an issue where using them within a TransactionScope during an exception will result in those logs being rolled back (database ones). Our solution is to wrap the calls in a TransactionScope with a Suppress option so it does not participate in the ambient transaction and we retain all logs.

Is this the correct approach for this? Assuming that is the correct approach, we are looking for a solution that will allow our developers to use the EntLib Logger.Write(...) methods as vanila as possible and so were looking for the best way to abstract this aspect. We "could" create our own wrapper around the Logger usage and do this BUT I don't like to introduce unecessary code and create many methods that just call the Logger.Write. So our thought is to create a custom LogWriterImpl deriving from the one in EntLib and wrap the calls in the Suppress (maybe make it configurable from Unity). I think we can do this programmatically after EntLib has initialized its EnterpriseLibraryContainer.Current but am trying to find a solution where I can define the replacement in a configuration file instead. Is this even possible?

If not, we will likely use an AppInstance.Initialize() method that all application would call in the infrastructure to manage these issues.

UPDATE: I noticed that we could inherit from LoggingSettings class that is the section for logging and possibly remove the programmatically set LogWriterImpl in favor of a configurable one during the GetRegistrations call. I will give this a try when I get in to see if that works for us.

Thoughts?

NOTE: We may move the logging to MSMQ at some point so it reduces the processing time and would eliminate this (as long as we are not using transaction queues) but that is not in the current implementation.

Thanks, Fred Hirschfeld

Aug 11, 2010 at 9:01 PM

Might I suggest that instead of replacing the LogWriter, you instead replace/modify the DatabaseTraceListener instead? You can put your transaction logic (or rather get-out-of-transaction logic) in there in the spot that's actually touching the database, and the config tool picks it up since you are plugging in at a specifically designed extension point instead.

Or am I missing something?

 

Aug 12, 2010 at 1:43 AM

That would work for this scenario specifically and I will give that a try. We were also looking to intercept the logging at the point in time it writes such that we could automatically inject (using unity) a collection of IExtra… (context suppliers but can’t remember the exact name) so that they could add the appropriate context at some point after Logger.Write but before sending to the listeners. Is there another point at which this could be achieved so that all logs have that data without requiring the app developers to specify?

From: ctavares [mailto:notifications@codeplex.com]
Sent: Wednesday, August 11, 2010 1:02 PM
To: fredhirschfeld@comcast.net
Subject: Re: Logging and TransactionScope [entlib:223209]

From: ctavares

Might I suggest that instead of replacing the LogWriter, you instead replace/modify the DatabaseTraceListener instead? You can put your transaction logic (or rather get-out-of-transaction logic) in there in the spot that's actually touching the database, and the config tool picks it up since you are plugging in at a specifically designed extension point instead.

Or am I missing something?

Read the full discussion online.

To add a post to this discussion, reply to this email (entlib@discussions.codeplex.com)

To start a new discussion for this project, email entlib@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com