Storing data as local file(s) (XML)
The scenario for this process is difficult to test in a single developer environment so I thought I'd throw it up here in the forum to get some feedback.
I recently got a web application set up on a remote web host. I don't have any database back-end available at the moment. Eventually, I'd like to do some basic data collection and would like to use XML for this purpose. I can handle writing what I need to read/change/save XML files. What I am concerned about is the issue of write access the XML file(s). My understanding of IIS (at least from when I was building simpler ASP applications) was that multiple page requests were/are processed sequentially in a first-come first-served basis. This would happen assuming that you have the application running in a single thread in IIS. I could be entirely wrong about this. My specialty is web applications, not web server inner workings :). How this all works in .Net is something I know nothing about, but would like to understand. Furthermore, I don't know how the web host's systems works.
If pages are processed in multiple threads such that many page requests can be processing simultaneously then I can foresee a couple problems:
1. When multiple requests are made to some page that manipulates data, and then the data is saved, some file access error(s) occur.
2. (More significant) Data inconsistencies occur:
a. Process 1 opens xml file, loads into object.
b. Process 2 opens xml file, loads into object.
c. Process 1 saves xml file.
d. Process 2 saves xml file. It's data is based on the original and will overwrite the changes process 1 made.
I think a way to overcome this problem is to let the data object(s) live at a higher scope. If they were kept in the Application() collection, then multiple processes would be working against the same instance of the object. (This is probably poor form and I'd like feedback regarding it. Furthermore, I know that the host frowns upon storing stuff like this in the application() collection anyway.)
Perhaps the best route I should take is to just fork over the cash (and it's not much anyway) for the basic MS-SQL services.
Thoughts, suggestions, feedback, discussion?
Peter
|
