Your class is multi-thread safe, but not multi-user (on different machines) safe. If that's your requirement, fine -- just want to make sure that you realize that the locking won't do anything useful if more than one machine is writing to the same file with this code. (I am uncertain whether the locking is sufficient if you have multiple AppDomains using this code to write to the same file -- Ian?)
If it's single-machine code, you could use Eric's suggestion of having a single thread do the logging in the background (where other threads just add to a queue), but that single thread would still need to re-write the file whenever it decides that it's holding too much data in the queue -- but the more gets written in one chunk, the less total work gets done. However, you have a bug in your code. As you apparently haven't noticed it yet, that means that you could fix it most easily by using the ASCIIEncoding class instead of the UTF8Encoding class. If you need to support UTF8 output (meaning that you can have non-ASCII chars in your log messages), then you should use utf8.GetByteCount rather than strData.Length to determine the size of the output buffer you're building. Again I'll point out that if you have control over how the people look at the file, or you can get them to run a simple program to produce a file they can read from the "live" log file, you can do better. If you use a "sparse file" to hold the data, and either write a program to load the file and display it (possibly in chunks, if it can be really big), or have them run a program that (once only) copies the real data to an ordinary text file, you won't be doing all that copying. Good luck... At 04:38 AM 11/19/2005, Girish Jain wrote >Thanks Ian, > >You got it correct, it's the IO cost and time constraint that I am worried >about. The log file is generated on a daily basis, still the amount of data >that is written to the log file is moderately large. > >I want the logging process to complete as fast as possible because when >multiple transactions are submitted simultaneously, one transaction should >not take a longer period to make other transactions slow. The amount of data >that is written to the log file is moderately large per transaction. > >Also, for the logging purpose I have built a wrapper class which holds all >the string data (using StringBuilder) that needs to be written for the >transaction and the final write is performed only once at the end of the >transaction so that the file is not blocked. > >Here's the class... >[snip] J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
