担心并发问题——我应该一次只允许1个用户吗?

本文关键字：1个 用户 一次 问题 并发 我应该 担心 | 更新日期: 2023-09-27 18:05:19

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

我的一个想法是创建一个锁，并且每次只允许一个用户管理。通过使用会话。SessionID并将其保存在应用程序状态中，作为独占锁。例如，如果用户想要管理，他首先会去一个登陆页面，那里会有这个检查(哦，这不是原子我拿它吗?):

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

和管理页面将有一个按钮来释放锁和重定向到另一个页面。或者如果用户忘记使用全局中的Session_End()。Asax文件并自动刷新。但这如何阻止别人按下浏览器的后退键并绕过这个呢?

或者我应该在写入配置文件之前确保配置文件没有被更改?但是我如何保存这个页面的状态呢?我是否应该在会话状态下保存文件修改时间，如果它们不一样，就放弃保存操作?

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

担心并发问题——我应该一次只允许1个用户吗?

调用应用程序。在访问您的文件之前锁定，然后您可以检查修改，然后在完成后释放锁定

Teletha，

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

MSDN Magazine Feb 2005:使用ReaderWriterLock类

MSDN - ReaderWriterLockSlim Class

Stack Overflow - ReaderWriterLock vs Lock

相关文章：