【问题标题】:Locking database record for editing锁定数据库记录以进行编辑
【发布时间】:2013-11-05 09:50:37
【问题描述】:

我有一个 SQL Server 2008 数据库和一个 asp.net 前端。

当用户当前正在编辑记录但不确定哪个是最佳方法时,我想实施锁定。

我的想法是为记录设置一个 isLocked 列,并在用户拉取该记录时将其设置为 true,这意味着所有其他用户在第一个用户完成编辑之前都具有只读访问权限。

但是,如果会话超时并且他/她从不保存/更新记录,记录将保留在isLocked = true,这意味着其他人无法编辑它,对吧?

如何实现某种会话超时并在会话超时(或在预定义的时间段之后)时自动将 isLocked 设置为 false

这应该在asp.net端还是SQL端实现?

【问题讨论】:

  • 您真的确定要这样做,而不是使用乐观锁定。有几种方法可以强制锁定 sql server,但它们开始变得混乱并变得更糟。

标签: asp.net sql locking


【解决方案1】:

根本不要这样做。请改用optimistic concurrency

悲观锁定是可能的,但不能来自 .Net 应用程序。 .Net 应用程序场在技术上无法维持长期会话以保持锁定(通过 sp_getapplock 获得,或者更糟糕的是,通过真实数据锁定获得),因为 .Net 应用程序场:

  • 跨实例负载平衡请求
  • 不要在 HTTP 调用之间保留请求堆栈
  • 回收应用域

在您说“我没有场,只有一个 IIS 服务器”之前,我要指出您可能只有一个 IIS 服务器现在,如果您依赖它,您将永远不会能够横向扩展,你仍然有应用域回收的问题。

通过应用程序特定更新(例如“is_locked”字段)模拟锁定在实际使用中存在严重缺陷,原因您已经开始看到等等。紧要关头,这是可以发挥作用的唯一方法,但我从未听说过任何人说“哎呀,我真的很高兴我们实现了悲观锁定数据写入!'。从来没有人。

应用层锁定也不可行,原因与 .Net 农场无法使用后端锁定(负载平衡、调用之间缺乏上下文、应用域回收)完全相同。编写分布式锁定应用程序协议是行不通的,那条路是用身体铺的。

只是不要这样做。乐观并发在各个方面都好得多。

【讨论】:

  • 感谢您的详细回复。就可扩展性而言,至少对于这个特定的应用程序,它永远不会超过 50 个用户,而且由于数据量不大,我什至可以使用数据集乐观并发,但我相信时间戳会更好一些。问题是,假设用户提取记录并在几个字段中输入大量数据/文本。然后同时另一个用户进入并进行快速的小更新。第一个用户的数据不会被保存(并且会丢失),但第二个用户应该永远无法进行更改。如何实现呢?
  • 更新丢失的原因有 0(零)个。该应用非常欢迎应用任何业务逻辑来合并更改,并在发生冲突时向用户显示一个新表单,要求协调冲突。
  • 有道理。如果我想通过更改多个表上的 1 行的存储过程执行时间戳检查,那么如何检查时间戳?
  • 这是业务逻辑。将取决于您的业务需求。
猜你喜欢
  • 1970-01-01
  • 2021-10-23
  • 1970-01-01
  • 1970-01-01
  • 2012-06-13
  • 1970-01-01
  • 1970-01-01
  • 2019-09-20
  • 2016-11-04
相关资源
最近更新 更多