在 ASP.NET 中存储记录锁定令牌
在我当前正在开发的应用程序中，多个用户可能想要同时编辑某些内容，这意味着我们需要实现乐观锁定。但是，对于此应用程序，正在编辑的项目是科学协议，其中包含数据库中多个不同表的记录。
因此，我们希望能够表明整个协议已被锁定以供单个用户编辑，这导致了我的问题：执行此操作的首选方法是否是在数据库级别事件编辑（例如，有一个带有协议的唯一 ID 并检查它是否已被锁定）或者是否会接受跟踪 Web 服务器本身内存中当前锁定的协议？
目前，我们预计该应用程序只有大约 100 个用户（大约同时 20 个），但这个数字将来可能会增加，因此我们希望使用最具可扩展性的选项。
In the application that I'm currently working on, it is possible for multiple users to want to edit something at the same time which means that we need to implement optimistic locking. However, for this application, the item being edited is a scientific protocol that contains records from multiple different tables in the database.
As such, we want to be able to indicate the entire protocol has been locked for editing by a single user which leads to my question: would the preferred method of doing this be to event the edits at the database level (e.g. have a table with the unique id of the protocol and check to see if it has been locked) or would it be accepted to track the currently locked protocols on the web server itself in memory?
Currently we only anticipate around 100 users (20 or so simultaneous) for the application, but that number may increase in the future so we are looking to use the most scalable option.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这个问题实际上还取决于您的代码库的架构如何？
如果修改这些记录的所有调用都通过单个入口点，那么是的，我建议将所有锁定代码完全保留在您的应用程序中，以便您可以将数据库保留为哑数据存储。
如果您有多个可以修改表的入口点，您将需要在数据库级别实现锁定。
This question also really hinges on how well architected is your codebase?
If all the calls to modify those records go through a single point of entry then yes I recommend keeping all locking code entirely in your application so you can keep your database as a dumb data store.
If you have multiple points of entry that can modify your tables you're going to need to implement locking at the database level.
我将在数据库中实现一个管理锁定的表。例如：
行：ProtocolID、EditingBeginDate、EditingEndDate
然后，您可以简单地查询何时尝试应用程序中的编辑功能，如果给定的协议没有完整的时间范围，那么您就知道给定的用户仍在编辑它。您可以设置编辑会话关闭的特定时间，以防止记录被永久锁定。只是一个建议:-D
I would implement a table in the database that managed the locking. For instance:
Rows: ProtocolID, EditingBeginDate, EditingEndDate
Then you can simply query when an edit function in the application is attempted and if the given protocol doesn't have a completed time frame then you know that it is still being edited by a given user. You can implement a specific amount of time that the editing sessions should be closed as to prevent records from being permanently locked. Just a suggestion :-D
所以，看来你需要粗粒度的锁。
如果您想拥有最具可扩展性的解决方案，则需要在数据库或分布式缓存中保留锁定信息（在这种情况下分布式缓存会更快）。内存方法根本不可扩展——如果您需要更多服务器，它就会失败。
不要忘记引入锁超时以防止可能的死锁。
So, it seems you need coarse grained locks.
If you want to have most scalable solution, you need to keep locking information either in database or distributed cache (distributed cache will be faster in this case). In-memory approach is not scalable at all - it is going to fail in case you need more servers.
Don't forget also to introduce lock time-outs to prevent possible deadlocks.