《悲观锁和乐观锁》由会员分享，可在线阅读，更多相关《悲观锁和乐观锁（26页珍藏版）》请在金锄头文库上搜索。
1、数据库悲观锁。由数据库的自身机制实现，当一些数据被读取时，这些数据便被锁住，别人是无法再读取。从而解决了并发访问时的更新丢失问题。优点：能够解决并发访问时更新丢失问题，并能保证用户的每次更新都是“命中”（成功）的。缺点：效率太差，当一个用户占据一些数据时，别的用户只能等待他完成操作或者锁过期。乐观锁。严格说，它并不是一种锁，只是一种“冲突检测”的机制而已。它需要在数据库表中额外添加一个字段（一般为version），用于检查提交上来的修改数据是否和读出去的数据的“版本”一致。如果一致，则证明没有人修改过该数据，允许提交。否则，不允许提交。而“版本”会随着数据的读取一同改变。优点：能有很好的效率，
2、用户可以任意读取。缺点：“命中”相对不高，有更新不成功，退回数据的情况，甚至直接导致输入的数据丢失。用什么锁，要视项目情况而定。Hibernate支持两种锁机制：即通常所说的“悲观锁(Pessimistic Locking)和“乐观锁(OptimisticLocking)。悲观锁的实现，往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据)Hibernate的加锁模式有：LockMode.NONE ： 无锁机制。Hibernate在Insert和Update记录的时候会自动获取。:Hibernat
3、e在读取记录的时候会自动获取。00 LockMode.WRITE :0 LockMode.READ以上这三种锁机制一般由Hibernate内部使用，如Hibernate为了保证Update过程中对象不会被外界修改，会在save方法实现中自动为目标对象加上WRITE锁。0 LockMode.UPGRADE :利用数据库的for update子句加锁。0 LockMode. UPGRADE_NOWAIT : Oracle 的特定实现，利用 Oracle 的 forupdate nowait子句实现加锁。乐观锁，大多是基于数据版本(Version)记录机制实现。何谓数据版本？即为数据增加一个版本标识
4、，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个“version”字段来实现。读取出数据时，将此版本号一同读出,之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。悲观锁与乐观锁的比较:悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受;相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，
5、由于乐观锁机制是在我们的系统中实现，来自外部系统的更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整(如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开)。Hibernate在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。Hiberna te中可以通过class描述符的opti mis tie-lock属性结合version描述符指定。optimistic-
6、lock属性有如下可选取值：0 none无乐观锁0 version通过版本机制实现乐观锁0 dirty通过检查发生变动过的属性实现乐观锁0 all通过检查所有属性实现乐观锁其中通过 version 实现的乐观锁机制是 Hibernate 官方推荐的乐观锁实现，同时也是 Hibernate 中，目前唯一在数据对象脱离 Session 发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择 version 方式作为 Hibernate乐观锁实现机制。6.3.1悲观锁定和乐观锁定http:/ 2009-06-17 23:27牛新庄 清华大学出版社 我要评论(0)摘要：深入解析DB2-高级管理
7、、内部体系结构与诊断案例第6章高级锁，本章我们介绍DB2中关于锁的一些高级内容。锁对数据库的并发影响很大，掌握锁的这些相关的技术对于我们合理地设计数据库和应用程序以保证提高数据库的并发性能具有重大意义。本节为大家介绍悲观锁定和乐观锁定。标签：陛数据库SQL深入解析DB2 Oracle帮您准确洞察各个物流环节6.3乐观锁6.3.1悲观锁定和乐观锁定悲观锁定DB2默认情况下都是采用悲观锁定方式工作，本节上面讲述的各个例子都属于这种情况。悲观锁定策略的前提是，另一个用户很可能试图修改您正在修改的某个表行。如果选择了某个行，并检测到其他用户试图对该行执行更新或删除操作，那么该 行将在这段时间内持有锁（
8、例如，通过使用RR隔离级别或以排它锁（X）模式锁定表）。悲观锁定的优点就是能够保证实现一致且安全的更改。但是这种锁定策略的主 要缺点就是并发性较差。对于具有大量用户或运行长期事务的系统，或者涉及大量SQL操作的事务，需要等待锁释放的概率则会增加。图6-3阐释了悲观锁定的功效。事务1读取某条特定记录并对该行应用一个锁，并且需要花些时间确定是否要对这个行执行更新操作。同时，事务2希望访问 这个行，但是它必须等待事务1释放该行的锁。也就是说，只有事务1释放锁后，事务2才能收到SELECT操作的结果并继续执行它的业务逻辑。（点击查看大图）图6-3悲观锁定的工作示意图乐观锁定悲观锁定方法的主要问题是事务
9、之间必须互相等待。避免发生这种情况的方法就是使用乐观锁定策略，即假设在修改某行时，另一个用户试图对这一行进行修 改的可能性极低。如果确实对这一行进行了修改，那么更新或删除操作将会失败，应用程序逻辑将处理这些失败，例如重新尝试选择。通过使用这种方法，使得事 务在对行执行选择、更新或删除操作期间，不会持有行锁。但是，由此产生的问题是需要一种方式确保数据在被读取和修改期间没有发生变化。尽管应用程序需要更多的重试逻辑，但乐观锁定策略的主要优点是通过最小化给定资源对其他事务的不可用时间，来减少锁竞争，同时不会牺牲数据完整性（虽然乐观锁定刚刚被引 入DB2 FOR Linux/UNIX/Windows，但
10、是早已被提供给DB2 FOR z/OS用户）。因此，它具有比悲观锁定更好的伸缩性。图6-4阐释了乐观锁定背后的思想。与图6-3类似，事务1读取某个特定记录，但随后即释放锁。因此，事务2现在可以顺利地对同一行进行检索。在提交事 务之前，事务1和事务2都必须检查该行在执行前面的SELECT之后是否发生改变。如果发生了一处修改，事务就必须重新执行新的SELECT来检索当前数据。然而，若该行在执行SELECT之后未发生变化，则可以成功更新数据。Start transaction!Start transact ion2TSelec tSelectNo：Oilier?NoYes：Order?J一fjl 亠
11、;Data was changed；:by transact ion 1： T -MFMr-M：WWRetryYesYesse 1 e c t ?UpdateComini tNo（点击查看大图）图6-4乐观锁定的工作示意图【责任编辑：云霞TEL: （010） 68476606】回书目 上一节 下一节悲观锁和乐观锁悲观锁和乐观锁POJOs in Action读书笔记（一）1事务隔离事务隔离是数据库提供的功能。SQL Server 通过 SET TRANSACTION ISOLATION LEVEL 语句设置事务隔离级别：SET TRANSACTION ISOLATION LEVEL READ U
12、NCOMMITTED| READ COMMITTED| REPEATABLE READ| SNAPSHOT| SERIALIZABLE;Read Committed是SQL Server的预设隔离等级。1.1 READ UNCOMMITTEDRead UnCommitted事务可以读取事务已修改，但未提交的的记录。Read UnCommitted 事务会产生脏读(Dirty Read)Read UnCommitted事务与select语句加nolock的效果一样，它是所有隔离级别中限制最少的。1.2 READ COMMITTEDRead Committed事务不能读取事务已修改，但未提交的记录
13、。Read Committed是SQL Server的预设隔离等级。1.3 REPEATABLE READRepeatable Read事务不能读取交易已修改，但未提交的记录，并且在事务完成之前，任何其它事务都不能修改目前事务已读取的记录。其它事务仍可以插入新记录，但必须符合当前事务的搜索条件这意味着当前事务重新查询记录时，会产生幻读(Phantom Read)。1.4 SNAPSHOTSnapshot事务中任何语句所读取的记录，都是事务启动时的数据。这相当于事务启动时，数据库为事务生成了一份专用“快照”在当前事务中看到不其它事务在当前事务启动之后所进行的数据修改。Snapshot事务不会读取
14、记录时要求锁定，读取记录的Snapshot事务不会锁住其它事务写入记录，写入记录的事务也不会锁住Snapshot事务读取数据。1.5 SERIALIZABLESerializable事务会产生以下效果：1. 语句无法读取其它事务已修改但未提交的记录。2在当前事务完成之前，其它事务不能修改目前事务已读取的记录。3在当前事务完成之前，其它事务所插入的新记录，其索引键值不能在当前事务的任何语句所读取的索引键范围中。Serializable事务与select语句加holdlock的效果一样。2 READ COMMITTED 和 REPEATABLE READRead Committed和 Repeat
15、able Read是最常用的两种事务。Read Committed 是 SQL Server 的默认级别；而 Repeatable Read 比 Read Committed 更能保证数据一致性。2.1特点Read Committed会阻塞其它事务中的update，但不会阻塞select。Repeatable Read不但会阻塞其它事务中的update，还会阻塞select0Read Committed和Repeatable Read的相同点是：都会阻塞其它事务的update语句。Read Committed 和 Repeatable Read 的不同点是：Read Committed 不会阻塞其它事务的 select 语句，但 Repeatable Read阻塞。注意，Read Committed和Repeatable Read都是行级锁，它们只会锁住与自己相关的记录。当事务提交之后，阻塞的语句就会继续执行。2.2理解221 READ COMMITTE
