我想知道如何在数据库驱动的应用程序中实现锁定的（更简单）方法（例如，在 c# 中，我指的是桌面应用程序或 Web 应用程序都连接到处理数据库操作的 WCF/Web 服务）。
我从这篇 wiki 文章http://en.wikipedia.org/wiki/Lock_(computer_science ) 了解到我可以进行乐观锁定，即检查自上次阅读后是否进行了更新并相应地抛出错误并要求用户重新阅读数据并尝试再次更新。但是如果有更多的用户同时进行更新，缺点是可能会有很多更新试验和错误。
作为结论，我认为乐观锁定是一种选择。是否还有其他实施起来并不复杂的选项？我认为锁定和互斥锁是一种选择，但我想不出一种方法来实现“如果”条件来查看哪个记录被阻止，这样就不会导致死锁。
避免死锁就是以正确的顺序获取锁。例如，在修改某个特定用户的数据之前，您可以 UPDLOCK 该用户，以便没有并发事务可以同时修改该用户。
这只是一个例子。你需要找到一个很可能以一致的顺序获取锁的方案。
对于读取，您可以使用快照隔离。
无论如何，许多应用程序只在特定位置出现死锁。也许您可以忽略该问题并通过更改少量代码来修复生产中的任何虚假死锁。
锁定数据的一种简单方法是在数据库上创建一个简单的表，其中包含以下列：
第 1 列：表名称 第 2 列：行 id 第 3 列：锁定（布尔值）毕竟您的软件可以读取此表以了解正在修改的记录。
您没有提及您使用或正在考虑的数据库产品。在 PostgreSQL 中（如果您可以选择），有一种技术类似于乐观并发控制 (OCC)，但用于SERIALIZABLE事务的回滚较少。它被称为可序列化快照隔离 (SSI)。基本上，OCC 基于单个读写反依赖取消事务，而 SSI 仅在存在多个读写反依赖的模式时才会取消事务，研究表明，如果不可序列化将始终存在效果是可能的。
这是一项新技术，于 2008 年首次发表在一篇学术论文中，并首次出现在 2011 年发布的 PostgreSQL 9.1 的公共生产数据库中。
显然还有很多其他方法可以解决这个问题，但您对 OCC 的兴趣似乎表明这可能对您有吸引力。面对并发事务时保持完整性的每种技术都将涉及阻塞、事务回滚或两者兼而有之。“传统的”严格两相锁定 (S2PL) 技术更倾向于阻塞，而 OCC 和 SSI 的阻塞最少（因此并发性更高），但在某些工作负载中可能有更多的回滚。使用的最佳技术绝对取决于工作量。
您可以在 SERIALIZABLE 事务隔离级别的 PostgreSQL 文档、带有一些示例的 Wiki 页面、 ACM SIGMOD 2008 的初始论文、Michael J. Cahill 的博士论文或 Dan RK Ports 和我本人的论文中阅读更多关于 SSI的信息已被接受在 VLDB 2012 上展示，并且应该很快由 VLDB 发布。