担心并发问题 - 我应该当时只允许 1 个用户吗？

Question

我正在为一个项目开发一个管理工具，该工具对不同的文件以及一些数据库查询和更新进行少量读写。 现在我相信我们不太可能遇到这个问题，因为我们使用这个项目的人并不多。 但如果可以的话，我想在不打扰普通用户的情况下尽量减少或消除它发生的风险。 我正在使用 Windows 身份验证和角色。

我的一个想法是创建一个锁，并且当时只允许 1 个用户进行管理。 通过使用 Session.SessionID 并将其保存在应用程序 state 作为排他锁。 例如，如果用户想要管理他会首先 go 到一个登录页面，然后这个检查在哪里（哦，这不是原子的，我认为它？）：

if (Application["lockedBy"] == null)
{
    Application["lockedBy"] = Session.SessionID;
    Application["lockedName"] = User.Identity.Name;
    Response.Redirect("Admin.aspx");
}

并且管理页面会有一个按钮来释放锁定并重定向到另一个页面。 或者，如果用户忘记使用 global.asax 文件中的 Session_End() 并进行自动刷新。 但这将如何阻止某人按下浏览器的后退按钮并绕过它呢？

或者我应该尝试确保在写入配置文件之前没有更改它们？ 但是我如何为这个页面保存 state。 我是否应该将文件修改时间保存在 Session state 中，如果它们存在差异，则只是中止保存操作？

所以问题是：我应该如何在不打扰普通用户的同时保护我的应用程序免受并发问题的影响？

Answer 1

在访问您的文件之前调用 Application.Lock ，然后您可以检查修改，然后在完成后释放锁定

Answer 2

泰丽莎，

我会尝试 ReaderWriterLockSlim（如果您有 3.5 或 4.0）或 ReaderWriterLock（2.0）而不是锁定。 它有两个队列，一个用于读取，一个用于写入。 即使不应该有那么多管理员用户，它在多线程环境中工作得更好，并且会减少（而不是消除）潜在的死锁。 在 ReaderWriterLockSlim 上查看 TryEnterWriteLock 方法。 它有一个可选的超时选项，但这对您的场景可能无关紧要。

MSDN 杂志 2005 年 2 月：使用 ReaderWriterLock Class

MSDN - ReaderWriterLockSlim Class

堆栈溢出 - ReaderWriterLock vs Lock