【发布时间】:2008-10-16 07:57:24
【问题描述】:
在记录锁定方面,我们正在尝试为我们的团队提供推荐的设计模式。典型的思想流派是这样的: 1. 用户从列表中选择一条记录 2.用用户id锁定记录 3.加载被锁定的记录记录(没有锁定,然后有人打你)。
我是否遗漏了什么,或者这似乎是唯一的方法? ((在我们的例子中,乐观锁定对于最终用户来说会很麻烦和困惑。编辑通常是相当大的。)
【问题讨论】:
标签: database concurrency locking
在记录锁定方面,我们正在尝试为我们的团队提供推荐的设计模式。典型的思想流派是这样的: 1. 用户从列表中选择一条记录 2.用用户id锁定记录 3.加载被锁定的记录记录(没有锁定,然后有人打你)。
我是否遗漏了什么,或者这似乎是唯一的方法? ((在我们的例子中,乐观锁定对于最终用户来说会很麻烦和困惑。编辑通常是相当大的。)
【问题讨论】:
标签: database concurrency locking
可能会使您的解决方案管理变得密集的细节是在崩溃或连接故障后摆脱锁定。这就是乐观锁定和悲观锁定之间的权衡的真正所在。当乐观锁定失败时手动合并或重做编辑是一件痛苦的事情,但是在悲观和持久锁定模型崩溃后清理会产生自己的麻烦(因为任何在 90 年代支持 Pervasive 支持的会计系统用户的人都会详细地告诉你机会)
一个答案是使用 RDBMS 的机制来管理事务和并发:使用 SELECT FOR UPDATE 或任何适合您的环境和隔离级别的语法来获取记录。如果您的客户端之一崩溃或断开连接,事务将回滚并释放锁。
在网络等无连接环境或连接丢失和恢复频繁的环境中,具有会话超时的基于会话的模型也可以工作:
所以当会话过期时锁会被释放。崩溃后不必手动删除锁,并且对客户端/连接问题有一定的容忍度。不过,编写代码确实需要更多的工作。
【讨论】: