数据库或用户级锁

Question

我目前面临以下问题:
我有一个连接到数据库的 C# .NET 应用程序(使用 NHibernate)。该应用程序基本上显示数据库内容并让用户对其进行编辑。由于应用程序的多个实例同时运行(在相同和不同的工作站上)，一旦两个用户同时修改同一条记录，我就会遇到并发问题。

目前我在一定程度上解决了乐观锁定的问题。但这不是完美的解决方案，因为一个用户仍然丢失了它的更改。

现在我想到了让应用程序在每次从数据库加载一个新条目时锁定一个条目并在用户切换到另一个条目时立即释放锁定的想法。所以基本上所有当前显示给用户的条目都被锁定在数据库中。如果另一个用户加载锁定的条目，它将以只读模式显示它们。

现在回答我的实际问题:
在数据库级别进行锁定是个好主意吗？这意味着每次用户加载新条目并锁定它时，我都会打开一个新事务。或者通过一个“锁定表”来完成它会更好吗？例如，它包含一个表中所有锁定条目的 key ？

感谢您的帮助!

Answer 1

Is it a good idea to do the locking on database level?

是的，在某些情况下没问题。

So basically all entries which are currently displayed to the user are locked in the database.
...
Or would it be better to do it through a "Lock Table" which holds for example a key to all locked entries in a table?

所以你在页面加载时锁定了一堆条目？你什么时候释放他们？如果编辑会花费很多时间(例如已经开始编辑条目然后去吃午饭)怎么办？如果用户在不编辑所有这些锁定的条目的情况下关闭页面，条目将保持锁定多长时间怎么办？
悲观锁定和“锁表”有助于避免乐观锁定的一些问题，但带来了新的问题。

Currently I kind of solved the issues with optimistic locking. But this is not the perfect solution since one user still looses its changes.

不能同意这是松散的，因为在您的情况下，如果验证和提交阶段作为单个原子操作执行，则条目不会被破坏并且只有一个事务会成功(假设它是第一个) ，另一个将回滚(第 2 个)。
根据NHibernate's Optimistic concurrency control

It will be atomic if only one of these database transactions (the last one) stores the updated data, all others simply read data.

The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning. NHibernate provides for three possible approaches to writing application code that uses optimistic concurrency.

因此第二个事务将被优雅地回滚，之后可以通知该用户他必须进行新编辑(新事务)或跳过此条目。

但一切都取决于您的业务逻辑和要求。如果您对数据的争用不高，因此不会有很多冲突，那么我建议您使用乐观锁定。