tags:

views:

15

answers:

1

I have inherited some code which involves a scheduled task that writes data (obtained from an external source) to XML files, and a website that reads said XML files to get information to be presented to the visitor.

There is no synchronization in place, and needless to say, sometimes the scheduled task fails to write the file because it is currently open for reading.

The heart of the writer code is:

XmlWriter writer = XmlWriter.Create(fileName);
try
{
  xmldata.WriteTo(writer);
}
finally
{
  writer.Close();
}

And the heart of the reader code is:

XmlDocument theDocument = new XmlDocument();
theDocument.Load(filename);

(yep no exception handling at either end)

I'm not sure how to best approach trying to synchronize these. As far as I know neither XmlWriter.Create() nor XmlDocument.Load() take any parameters regarding file access modes. Should I manage the underlying FileStreams myself (with appropriate access modes) and use the .Create() and .Load() overloads that take Stream parameters?

Or should I just catch the IOExceptions and do some sort of "catch, wait a few seconds, retry" approach?

A: 

Provided that your web site does not need to write back to the XmlDocument that is loaded, I would load it via a FileStream that has FileShare.ReadWrite set. That should allow your XmlWriter in the other thread to write to the file.

If that does not work, you could also try reading the xml from the FileStream into a MemoryStream, and close the file as quickly as possible. I would still open the file with FileShare.ReadWrite, but this would minimize the amount of time your reader needs to access data in the file.

By using FileShare.ReadWrite (or FileShare.Write for that matter) as the sharing mode, you run the risk that the document is updated while you are still reading it. That could result in invalid XML content, preventing the XmlDocument.Load call from successfully parsing it. If you wish to avoid this, you could try synchronizing with a temporary "locking file". Rather than allowing file sharing, you prevent either thread from concurrently accessing, and when either of them is processing the file, write an empty, temporary file to disk that indicates this. When processing (reading or writing) is done, delete the temporary file. This prevents an exception from being thrown on either end, and allows you to synchronize access to the file.

There are a couple other options you could use as well. You could simply let both ends swallow any exception and wait a short time before trying again, although that isn't really the best design. If you understand the threading options of .NET well enough, you could also use a named system Mutex that both processes (your writing process and your web site process) know about. You could then use the Mutex to lock, and not have to bother with the locking file.

jrista
Thanks for that - I think I'll go with the approach of using a FileShare.ReadWrite FileStream on the reads. My prime concern is making sure the updates never fail due to the file currently being read from, and this approach should guarantee that, right?
Carson63000
It should guarantee the updates do not fail, however the web site could fail with an exception if the document changes while it is being read.
jrista