Hibernate 乐观锁(Optimistic Locking)

  1、hibernate基于数据版本(Version)记录机制实现。为数据增加一个版本标识,一般是通过为数据库表增加一个“version”字段来实现。 读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据 版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。

  2、

 1 //$Id: Conductor.java 11282 2007-03-14 22:05:59Z epbernard $
 2 package org.hibernate.test.annotations.various;
 3
 4 import javax.persistence.Column;
 5 import javax.persistence.Entity;
 6 import javax.persistence.GeneratedValue;
 7 import javax.persistence.Id;
 8 import javax.persistence.Version;
 9
10 import org.hibernate.annotations.Index;
11 import org.hibernate.annotations.OptimisticLock;
12
13
14 @Entity
15 public class Conductor {
16     @Id
17     @GeneratedValue
18     private Integer id;
19     @Column(name = "cond_name")
20     @Index(name = "cond_name")
21     <span style="color: rgb(255, 0, 0);">//@OptimisticLock(excluded = true)</span>
22
23     private String name;
24     @Column(name = "cond_address")
25     @Index(name = "cond_address")
26     <span style="color: rgb(255, 0, 0);">@OptimisticLock(excluded = true)</span>
27
28     private String address;
29     @Version
30     private Long version;
31
32 }
33  address是本人加上的.同时省略了get set方法.
34 测试:
35 Java代码
36 //$Id: IndexTest.java 11282 2007-03-14 22:05:59Z epbernard $
37 package org.hibernate.test.annotations.various;
38
39 ...........................
40
41
42 public class IndexTest extends TestCase {
43     ...............
44
45     @SuppressWarnings("unchecked")
46     public void testVersion() throws Exception {
47
48         Session session1=openSession();
49         Session session2=openSession();
50         Conductor stu1=(Conductor)session1.createQuery("from Conductor as a where a.name=‘Bob‘").uniqueResult();
51         Conductor stu2=(Conductor)session2.createQuery("from Conductor as a where a.name=‘Bob‘").uniqueResult();
52
53         //这时候,两个版本号是相同的
54         System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());
55
56         Transaction tx1=session1.beginTransaction();
57         stu1.setName("session1");
58         tx1.commit();
59         //这时候,两个版本号是不同的,其中一个的版本号递增了
60         System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());
61
62         Transaction tx2=session2.beginTransaction();
63         stu2.setName("session2");
64
65         tx2.rollback();
66         session2.close();
67         session1.close();
68     }
69     ............
70 }  

  添加testVersion方法。

时间: 2024-10-27 04:44:00

Hibernate 乐观锁(Optimistic Locking)的相关文章

乐观锁(optimistic locking)与悲观锁(pessimistic locking)

首先,乐观锁(optimistic locking)与悲观锁(pessimistic locking)基本是针对数据处理来说,也就是跟数据库有关的术语,目的是为了解决并发处理时所遇到的相关性能问题,以避免数据丢失更新. 悲观锁(pessimistic locking):指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态,以保证操作最大程度的独占性,当然也就给数据库增加了大量开销降低了性能.一般依靠数据库提供的锁

hibernate 乐观锁与悲观锁使用

Hibernate支持两种锁机制: 即通常所说的"悲观锁(Pessimistic Locking)"和 "乐观锁(OptimisticLocking)". 悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据). Hibernate的加锁模式有: ? LockMode.NONE : 无锁机制. ? LockMode.WRITE :Hibernate在Ins

Hibernate乐观锁、悲观锁和多态

 乐观锁和悲观锁 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁. 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等

HIbernate乐观锁与悲观锁

悲观锁 从加载对象就开始锁定.修改过程中一直是锁.直到commit()提交后再解锁.只需要在加载对象时加上(LockOptions.UPGRADE)即可,如下所示 Info info=session.load(Info.class,"p003",LockOptions.UPGRADE); 这样带来的问题就是,当访问量大的时候就会造成排队等待的后果. 乐观锁 相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制.悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性.但随之而

web开发中的两把锁之数据库锁:(高并发--乐观锁、悲观锁)

这篇文章讲了 1.同步异步概念(消去很多疑惑),同步就是一件事一件事的做:sychronized就是保证线程一个一个的执行. 2.我们需要明白,锁机制有两个层面,一种是代码层次上的,如Java中的同步锁,典型的就是同步关键字synchronized ( 线    程级别的).另一个就是数据库层次上的,比较典型的就是悲观锁和乐观锁. 3.常见并发同步案例分析   附原文链接 http://www.cnblogs.com/xiohao/p/4385508.html 对于我们开发的网站,如果网站的访问

乐观锁解决高并发

对于我们开发的网站,如果网站的访问量非常大的话,那么我们就需要考虑相关的并发访问问题了.而并发问题是绝大部分的程序员头疼的问题, 但话又说回来了,既然逃避不掉,那我们就坦然面对吧~今天就让我们一起来研究一下常见的并发和同步吧. 为了更好的理解并发和同步,我们需要先明白两个重要的概念:同步和异步    1.同步和异步的区别和联系          所谓同步,可以理解为在执行完一个函数或方法之后,一直等待系统返回值或消息,这时程序是出于阻塞的,只有接收到 返回的值或消息后才往下执行其它的命令. 异步

【转】MySQL乐观锁在分布式场景下的实践

背景 在电商购物的场景下,当我们点击购物时,后端服务就会对相应的商品进行减库存操作.在单实例部署的情况,我们可以简单地使用JVM提供的锁机制对减库存操作进行加锁,防止多个用户同时点击购买后导致的库存不一致问题. 但在实践中,为了提高系统的可用性,我们一般都会进行多实例部署.而不同实例有各自的JVM,被负载均衡到不同实例上的用户请求不能通过JVM的锁机制实现互斥. 因此,为了保证在分布式场景下的数据一致性,我们一般有两种实践方式:一.使用MySQL乐观锁:二.使用分布式锁. 本文主要介绍MySQL

锁( locking )

业务逻辑的实现过程中,往往需要保证数据访问的排他性.如在金融系统的日终结算处理中,我们希望针对某个 cut-off 时间点的数据进行处理,而不希望在结算进行过程中(可能是几秒种,也可能是几个小时),数据再发生变化.此时,我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改,这样的机制,在这里,也就是所谓的 “锁” ,即给我们选定的目标数据上锁,使其无法被其他程序修改.Hibernate 支持两种锁机制:即通常所说的 “悲观锁( Pessimistic Locking )”和 “乐观

乐观锁与悲观锁的应用场景

锁( locking ) 业务逻辑的实现过程中,往往需要保证数据访问的排他性.如在金融系统的日终结算 处理中,我们希望针对某个 cut-off 时间点的数据进行处理,而不希望在结算进行过程中 (可能是几秒种,也可能是几个小时),数据再发生变化.此时,我们就需要通过一些机 制来保证这些数据在某个操作过程中不会被外界修改,这样的机制,在这里,也就是所谓 的 " 锁 " ,即给我们选定的目标数据上锁,使其无法被其他程序修改. Hibernate 支持两种锁机制:即通常所说的 " 悲