Worrying about concurrency issues - should I only allow 1 user at the time?

I’m working on an administration tool for a project that does a small amount of reading and writing to different files and some database queries and updates. Now I believe it’s improbable that we would ever have an issue with this since we’re not that many people using this project. But if I can, I want to minimize or eliminate the risk of it ever happening while not disturbing the normal users. I'm using Windows Authentication and Roles.

One of my ideas is to create a lock and only allowing 1 user to administer at the time. By using the Session.SessionID and saving it in the Application state as an exclusive lock. E g if a user would want to administer he would first go to a landingpage and there where would be this check (oh, this isn't atomic I take it?):

if (Application["lockedBy"] == null)
{
  开发者_运维问答  Application["lockedBy"] = Session.SessionID;
    Application["lockedName"] = User.Identity.Name;
    Response.Redirect("Admin.aspx");
}

And the admin page there would be a button to release the lock and redirect to another page. Or if the user forgets using the Session_End() in the global.asax file and having an autorefresh. But how would this stop someone from pressing the browsers backbutton and bypassing this?

Or should I try to make sure the configuration files haven’t been changed before writing to them? But how would I save the state for this page. Should I like save the files modification time in Session state and if they diff just abort the save action?

So the question is: how should I protect my application from concurrency issues while not disturbing the normal users?

---

Call Application.Lock before accessing your files and then you can check for modifications and then release the lock when you have finished

---

Teletha,

I'd try ReaderWriterLockSlim (if you have 3.5 or 4.0) or ReaderWriterLock (2.0) instead of lock. It has two queues one for reads and one for writes. Even though there shouldn't be that many admin users it works better in a multi threaded environment and would reduce (not remove) the potentials deadlocks. On the ReaderWriterLockSlim look at the TryEnterWriteLock method. It has an optional timeout option, but that may not matter for your scenario.

MSDN Magazine Feb 2005: Using the ReaderWriterLock Class

MSDN - ReaderWriterLockSlim Class

Stack Overflow - ReaderWriterLock vs Lock