hibernate 锁机制

有的人在想 “隔离级别” 不就是为了保证高并发数据安全性吗。既然有了这个为什么还有锁机制啊？隔离级别的安全控制是整体一个大的方面，而锁机制更加的灵活，它执行的粒度可以很小，可以在一个事务中存在。而且有了锁机制数据安全可谓是如虎添翼安全性更是大大的提高。
hibernate 提供了两种锁机制 乐观锁和悲观锁
乐观锁：在一个线程进行修改的时候，总不会出现另一个线程也在修改
悲观锁：一个线程存储的时候，总会有一个线程同时进行修改

有哪些锁类型
参考文献：[url]http://gary0416.iteye.com/blog/888682[/url]

共享锁

加锁条件：当一个事务进行查询的时候,数据库就会给事务分配一个共享锁。锁定查询的数据，锁都是由数据库分配
解锁条件：数据查询完毕
兼容性：可以兼容更新锁
并发性能：并发性能高，多个事务读相同数据时，给每个事务分配一个共享锁


更新锁
加锁条件：当事务进行update更新时，将会获得一把更新锁
解锁条件：事务执行查询完毕，进行更新的时候，更行锁自动升级为独占锁
兼容性：可以兼容共享锁
并发性能：并发性能一般，因为升级为独占锁的时候，多个事务可以有共享锁，但只允许一个事务对数据进行更改，对数据进行锁定

独占锁
加锁条件：当事务进行，delete，update，insert操作时，将会得到独占锁
解锁条件：事务delete，update，insert操作完毕
兼容性：不能兼容共享锁和更型锁
并发性能：并发性能低，一次只允许一个事务对数据进行更改，锁定更新的内容，如果有多个事务，那其他的事务就得等待。

怎么实现乐观锁机制
hibernte 推荐是版本控制，在数据里增加一个字段，标识版本，字段值由数据库维护

实体类的映射文件

<hibernate-mapping>

    <class name="org.myhibernate.entity.TbStudent" table="tb_Student" catalog="hibernate_db" optimistic-lock="version" >

    	<!--  <cache usage="read-write"/>-->
        <id name="id" type="java.lang.Integer">
            <column name="id" />
            <generator class="native" />
        </id>
        <!-- 版本控制 -->
       <version name="version" type="java.lang.Integer"></version>
</hibernate-mapping>

注意：<class optimistic-lock="version">这个必须加上，只是告诉数据库启用版本控制，检查<version>/<timestamp>

non:不启用乐观锁
version:启用乐观锁机制的版本控制
dirty:更新时检查有更新的属性，达到乐观锁机制
all:检查所有属性，达到乐观锁机制（这个主要是你的项目没的源码的时候，你又想实现乐观锁，那你只有配置这个就行了，hibernate的开发人员想的听全面）


你不用版本控制，也可以改用时间戳

<timestamp name="timestamps"></timestamp>

当两个事务同时查询，得到相同的版本，其中的A一个事务更新了，此时数据的版本就改变了，B事在去更新 异常 StaleObjectStateException。数据库的版本和要更新的版本不一致。
在这里我对异常处理，让它重新更新，还是报这个错，我以为是缓存的原因干扰了，把缓存去掉，也还是报这个错，现在有点纠结，有知道的同志可以留言啊？？？？代码在下面

public class TestVersion{
	private static Session  session=SessionFactoryUtil.getSession();
	private static TbStudent s1;
	private static TbStudent s2;
	static{

		s1=(TbStudent)session.get(TbStudent.class, 1);
		s2=(TbStudent) session.get(TbStudent.class, 1);
	}

	private static int i=0;
	public TestVersion(){};

	public static void main(String[] args) {

		new Thread(new Runnable() {

			@Override
			public void run() {
				try{
				session.beginTransaction();
				s1.setClassname(""+new Random().nextInt(1000));
				session.update(s1);
				session.beginTransaction().commit();
				}catch(StaleObjectStateException s){
					run();
				}
			}
		}).start();

		new Thread(new Runnable() {

					@Override
					public void run() {
						try{
						session.beginTransaction();
						int s=new Random().nextInt(1000);
						s2.setClassname(""+s);
						session.update(s2);
						session.beginTransaction().commit();

						}catch(StaleObjectStateException s){
							run();
						}
					}
				}).start();
			}
}

配置文件
<property name="hibernate.cache.use_second_level_cache">false</property>

[img]http://dl.iteye.com/upload/attachment/0070/5000/a568e1d5-befd-34a5-bfee-4808e5cc61c2.png[/img]


乐观锁已经实现了，那么悲观锁怎么实现？


none:没有锁，查询的时候，先到缓存中去查，没有select数据库
read:查询的时候,到数据库去select,不到缓存
UPGRADE:升级锁,更行锁到独占锁，采用select for update,先拥有更新所，在查询数据的时候，更新的时候，资源锁定，变为独占锁。
UPGRADE_NOWAIT：升级锁不等到。当一个事务在更新的时候，已加锁，如果有其他的时候也想更新，那么事务结束。不在排队等候
WRITE ：这个是hibernate自己内部使用的。我们不需要关心

怎么应用悲观锁

XX entity=session.get("entityname",id,LockMod)
entity=setxx();

我在使用悲观锁的时候
Lock wait timeout exceeded; try restarting transaction,
等待超时

我做了个实验，两个线程得到不是同一条数据，但同样会报上边那个异常，那么独占锁是行锁定，还是表锁定？？这里有点疑问，如果是表锁定的话，那真的是并发性能真的很差
[b]欢迎大家指正，和交流[/b]