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.
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