J
Johan Karlsson
Hi!
What is the best practice for this given scenario.
I have a singleton object that lives inside a windows service.
This object is accessed by clients using .NET remoting. The problem is when
it comes to logging. I want log events to be written to a custom textfile in
order to keep compatibilty with some older logreaders for this project.
As it is today, other methods call the Log function on the singleton object
that in turn opens a textfile, writes a row and then closes the textfile.
Not so often this leads to a sharing violation.
What is the best practice here?
Should I open the file at startup of the service and keep it open until the
end of the day. (Logging keeps one file a day).
Should I build some kind of loggingbuffer mechanism that runs in its own
thread and that flushes its content down to disk every now and then? This
sound like complicating things and adding complexity where I dont need it,
and the log will not be up-to-date between saves.
Or could I just create somekind of lock here on a shared object? Like this
-------------------------
m_logObject As Object '* instanciated to something later on...
Sub Log( .. arguments .. )
SyncLock m_logObject
WriteToFile()
End SyncLock
End Sub
-------------------------
Any suggestions to other approaches are very welcome!
Thanks
Johan
What is the best practice for this given scenario.
I have a singleton object that lives inside a windows service.
This object is accessed by clients using .NET remoting. The problem is when
it comes to logging. I want log events to be written to a custom textfile in
order to keep compatibilty with some older logreaders for this project.
As it is today, other methods call the Log function on the singleton object
that in turn opens a textfile, writes a row and then closes the textfile.
Not so often this leads to a sharing violation.
What is the best practice here?
Should I open the file at startup of the service and keep it open until the
end of the day. (Logging keeps one file a day).
Should I build some kind of loggingbuffer mechanism that runs in its own
thread and that flushes its content down to disk every now and then? This
sound like complicating things and adding complexity where I dont need it,
and the log will not be up-to-date between saves.
Or could I just create somekind of lock here on a shared object? Like this
-------------------------
m_logObject As Object '* instanciated to something later on...
Sub Log( .. arguments .. )
SyncLock m_logObject
WriteToFile()
End SyncLock
End Sub
-------------------------
Any suggestions to other approaches are very welcome!
Thanks
Johan