Question

我正在为一个项目开发一个管理工具，该项目对不同的文件和一些数据库查询和更新进行少量读写。现在我认为，由于我们并没有那么多人使用这个项目，因此我们不可能遇到这个问题。但是，如果可以，我希望尽量减少或消除它发生的风险，同时不打扰正常用户。我正在使用Windows身份验证和角色。

我的一个想法是创建一个锁，当时只允许1个用户进行管理。通过使用Session.SessionID并将其作为独占锁保存在Application状态中。例如，如果用户想要管理他将首先进入登陆页面，那里将进行此检查（哦，这不是原子的，我接受了吗？）：

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

管理页面会有一个按钮来释放锁定并重定向到另一个页面。或者，如果用户忘记在global.asax文件中使用Session_End（）并具有autorefresh。但是，这会阻止某人按下浏览器后退按钮并绕过它？

或者我应该在写入之前尝试确保配置文件没有更改？但是我如何保存此页面的状态。我是否应该在Session状态下保存文件修改时间，如果它们只是中止保存操作？

所以问题是：如何在不扰乱普通用户的情况下保护我的应用程序免受并发问题的影响？

Answer 1

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

Answer 2

Teletha，

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

MSDN Magazine Feb 2005: Using the ReaderWriterLock Class

MSDN - ReaderWriterLockSlim Class

Stack Overflow - ReaderWriterLock vs Lock

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

2 个答案: