我理解乐观和悲观锁定*之间的区别.现在有人可以向我解释我何时会使用其中任何一个？
这个问题的答案是否会根据我是否使用存储过程来执行查询而改变？
*但只是为了检查,乐观的意思是"在阅读时不要锁定桌子",悲观意味着"在阅读时锁定桌面".
乐观锁定是一种策略,您可以在其中读取记录,记录版本号(其他方法包括日期,时间戳或校验和/哈希),并在写回记录之前检查版本是否未更改.当你写回记录时,你过滤版本的更新,以确保它是原子的.(即,在检查版本并将记录写入磁盘之间未进行更新)并在一次更新中更新版本.
如果记录是脏的(即与您的版本不同),则中止事务并且用户可以重新启动它.
此策略最适用于大容量系统和三层体系结构,在这些体系结构中,您不必为会话维护与数据库的连接.在这种情况下,客户端实际上无法维护数据库锁,因为从池中获取连接,并且您可能没有使用从一个访问到下一个访问的相同连接.
悲观锁定是指您在完成操作之前锁定专用的记录.它具有比乐观锁定更好的完整性,但要求您小心应用程序设计以避免死锁.要使用悲观锁定,您需要直接连接到数据库(通常是双层客户端服务器应用程序中的情况)或可以独立于连接使用的外部可用事务ID.
在后一种情况下,您使用TxID打开事务,然后使用该ID重新连接.DBMS维护锁定并允许您通过TxID选择备份会话.这就是使用两阶段提交协议(例如XA或COM +事务)的分布式事务的工作方式.
当您不期望很多碰撞时使用乐观锁定.执行正常操作的成本较低,但如果发生冲突,则在交易中止时您将支付更高的价格来解决它.
当预期发生碰撞时使用悲观锁定.简单地阻止了违反同步的事务.
要选择正确的锁定机制,您必须估计读取和写入的数量并相应地进行规划
乐观地假设在你阅读时没有任何改变.
悲观假设某些东西将会锁定它.
如果数据完全读取并不重要,请使用乐观.你可能会得到奇怪的"脏"读 - 但它不太可能导致死锁等.
大多数Web应用程序都可以使用脏读 - 在极少数情况下,数据与下次重新加载不完全相符.
对于精确的数据操作(如在许多金融交易中),使用悲观.准确读取数据至关重要,没有未显示的变化 - 额外的锁定开销是值得的.
哦,并且Microsoft SQL服务器默认为页面锁定 - 基本上是您正在阅读的行以及其中的一些.行锁定更准确但速度更慢.通常值得将事务设置为read-committed或no-lock以避免在读取时出现死锁.
除了已经说过的内容之外,应该说乐观锁定倾向于以牺牲可预测性为代价来改善并发性.悲观锁定往往会降低并发性,但更容易预测.
你支付你的钱等
当悲观锁定是更好的选择时,我会想到另一种情况.
对于乐观锁定,数据修改中的每个参与者必须同意使用这种锁定.但是如果有人修改数据而不关心版本列,这将破坏乐观锁定的整个想法.
基本上有两个最受欢迎的答案.在第一个基本上说
乐观需要一个三层体系结构,在这种体系结构中,您不必为会话保持与数据库的连接,而悲观锁定是指您在完成操作之前锁定记录以供独占使用.与乐观锁定相比,它具有更好的完整性,您需要直接连接到数据库.
另一个答案是
乐观(版本控制)更快,因为没有锁定但是(悲观)锁定在争用较高时表现更好,并且最好防止工作而不是丢弃它并重新开始.
要么
当您遇到罕见的碰撞时,乐观锁定效果最佳
因为它被放在这个页面上.
我创建了我的答案来解释"保持连接"与"低冲突"的关系.
要了解哪种策略最适合您,请不要考虑数据库具有的每秒事务数,而是考虑单个事务的持续时间.通常,您打开trasnaction,performa操作并关闭事务.这是一个简短的经典事务ANSI已经考虑到并且很好地逃脱了锁定.但是,您如何实施预订系统,许多客户同时预订相同的房间/座位？
您浏览优惠,填写表格,提供大量可用选项和当前价格.这需要花费很多时间,选项可能会过时,所有价格之间的价格无效,你开始填写表格并按下"我同意"按钮,因为你访问过的数据没有锁定,其他人,更敏捷,有意思更改所有价格,您需要重新启动新价格.
您可以在阅读时锁定所有选项.这是一种悲观的情景.你明白为什么它很糟糕.您的系统可以由一个只是开始预订并吸烟的小丑打倒.在他结束之前,没有人能保留任何东西.您的现金流量降至零.这就是为什么乐观的保留在现实中使用.那些磨蹭太久的人必须以更高的价格重新开始预订.
在这种乐观的方法中,您必须记录您读取的所有数据(如我的重复读取)并使用您的数据版本到达提交点(我想以您在此报价中显示的价格购买股票,而不是当前价格).此时,将创建ANSI事务,它会锁定数据库,检查是否有任何更改并提交/中止您的操作.IMO,这是MVCC的有效模拟,它也与Optimistic CC相关联,并假设您的事务在中止的情况下重新启动,即您将进行新的预订.此处的交易涉及人类用户决策.
我不太了解如何手动实现MVCC,但我认为长期运行的事务选项是重启是了解主题的关键.如果我在任何地方都错了,请纠正我.我的答案是由Alex Kuznecov章节推动的.
在大多数情况下,乐观锁定更有效,并提供更高的性能.在悲观锁定和乐观锁定之间进行选择时,请考虑以下事项:
如果用户尝试同时更新数据有很多更新和相对较高的机会,则悲观锁定很有用.例如,如果每个操作一次可以更新大量记录(银行可能会在每个月末向每个帐户添加利息收入),并且两个应用程序同时运行此类操作,则会发生冲突.
在包含经常更新的小表的应用程序中,悲观锁定也更合适.在这些所谓的热点的情况下,冲突很可能是乐观锁定浪费了回滚冲突交易的努力.
如果冲突的可能性非常低,则乐观锁定很有用 - 有许多记录但用户相对较少,或者很少更新,而且大多数是读取类型的操作.
处理冲突时，有两种选择：
您可以尝试避免冲突，这就是悲观锁的作用。
或者，您可以允许发生冲突，但是在提交事务时需要检测到冲突，这就是乐观锁定的作用。
现在，让我们考虑以下丢失更新异常：
丢失更新异常可能发生在“ 读取已提交”隔离级别中。
在上图中，我们可以看到Alice相信她可以从她account的帐户中提取40英镑，但没有意识到Bob刚刚更改了帐户余额，现在该帐户中只剩下20个了。
悲观锁定通过对帐户进行共享或读取锁定来实现此目标，因此可以防止Bob更改帐户。
在上图中，Alice和Bob都将获得account两个用户都已读取的表行的读取锁。使用“可重复读”或“可序列化”时，数据库将在SQL Server上获取这些锁。
由于Alice和Bob都已读取accountPK值为的1，因此他们都无法更改它，直到一个用户释放读取锁。这是因为写操作需要获取写/排他锁，而共享/读锁会阻止写/排他锁。
只有在Alice提交了事务并account在行上释放了读取锁之后，Bob UPDATE才会恢复并应用更改。在Alice释放读取锁之前，Bob的UPDATE会阻塞。
有关数据访问框架如何使用底层数据库悲观锁定支持的更多详细信息，请参阅本文。
乐观锁定允许发生冲突，但是在版本更改后应用Alice的UPDATE时会检测到冲突。
这次，我们还有一个version专栏。version列每次执行UPDATE或DELETE时都会增加，并且在UPDATE和DELETE语句的WHERE子句中也使用该列。为此，我们需要version在执行UPDATE或DELETE之前发出SELECT并读取当前值，否则，我们将不知道将哪个版本值传递给WHERE子句或进行递增。
有关数据访问框架如何实现乐观锁定的更多详细信息，请参阅本文。
关系数据库系统已经出现在70年代末80年代初，当时客户通常会通过终端连接到大型机。这就是为什么我们仍然看到数据库系统定义诸如SESSION设置之类的术语的原因。
如今，通过Internet，我们不再在同一数据库事务的上下文中执行读写操作，而ACID不再足够。
例如，考虑以下用例：
没有乐观锁定，即使数据库事务使用了Serializable，也不会捕获此丢失的更新。这是因为读写是在单独的HTTP请求中执行的，因此是在不同的数据库事务上执行的。
因此，即使在使用包含用户思考时间的应用程序级事务时，乐观锁定也可以帮助您防止丢失更新。
有关应用程序级或逻辑事务的更多详细信息，请参阅本文。
乐观锁定是一种非常有用的技术，即使在使用不太严格的隔离级别（如“读取已提交”）或在后续数据库事务中执行读写操作时，它也可以正常工作。
乐观锁定的缺点是，在捕获到时OptimisticLockException，数据访问框架会触发回滚，因此会丢失当前正在执行的事务之前我们所做的所有工作。
争用越多，冲突越多，中止交易的机会就越大。由于数据库系统需要还原所有可能涉及表行和索引记录的所有当前挂起的更改，因此回滚对于数据库系统而言可能是昂贵的。
因此，当冲突频繁发生时，悲观锁定可能比较适合，因为它减少了回滚事务的机会。
京公网安备 11010802040832号 | 京ICP备19059560号-6 