数据库ACID特征:
A. Atomic(原子性):指整个数据库事务是不可分割的工作单元。
B. Consistency(一致性):指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。
C. Isolation(隔离性):指的是在并发环境中,当不同的事务同时操纵相同的数据时,每个事务都有各自的完整数据空间。
D. Durability(持久性):指的是只要事务成功结束,它对数据库所作的更新就必须永久保存下来。
并发引起的问题:
A. 第一类丢失更新:撤销一个事务时,把其他事务已提交的更新数据覆盖。
B. 脏读:一个事务读到另一个事务未提交的更新数据。 (更新数据时发生)
C. 幻像读:一个事务读到另一个事务已提交的新插入的数据。 (添加或删除数据时发生)
D. 不可重复读:当事务1读取了一条记录,该记录为事务2未提交事务记录中,事务2修改了该条记录并且提交事务;事务1又读取了该条记录,发现两条记录不一样。 (修改数据时发生)
E. 第二类丢失更新:这是不可重复读中的特例,一个事务覆盖另一个事务已提交的更新数据。
数据库系统提供了四种事务隔离级别供用户选择:
A. Serializable(串行化):一个事务在执行过程中完全看不到其他事务对数据库所做的更新。 实际上是独占方式读取数据。
B. Repeatable Read(可重复读):一个事务在执行过程中可以看到其他事务已经提交的新插入的记录,但是不能看到其他事务对已有记录的更新。 锁定查询中使用的所有数据以防止修改(避免脏读和不可重复读),但是不防止插入数据,这时重新读取时,就会读到之前没读到的数据,出现了幻读。此隔离级别允许出现幻读。
C. Read Commited(读已提交数据):一个事务在执行过程中可以看到其他事务已经提交的新插入的记录,而且能看到其他事务已经提交的对已有记录的更新。
D. Read Uncommitted(读未提交数据):一个事务在执行过程中可以看到其他事务没有提交的新插入的记录,而且能看到其他事务没有提交的对已有记录的更新。
隔离级别 | 脏读 | 不可重复读 | 幻读 |
读未提交 | 是 | 是 | 是 |
读已提交 | 否 | 是 | 是 |
可重复读 | 否 | 否 | 是 |
可序列化 | 否 | 否 | 否 |
hibernate锁可以分为以下几类:
1.悲观锁
它指的是对数据被外界修改持保守态度。假定任何时刻存取数据时,都可能有另一个客户也正在存取同一笔数据,为了保持数据被操作的一致性,于是对数据采取了数据库层次的锁定状态,依靠数据库提供的锁机制来实现。
基于jdbc实现的数据库加锁如下:
select * from account where name="Erica" for update
在更新的过程中,数据库处于加锁状态,任何其他的针对本条数据的操作都将被延迟。本次事务提交后解锁。
而hibernate悲观锁的具体实现如下:
String sql="查询语句";Query query=session.createQuery(sql);query.setLockMode("对象",LockModel.UPGRADE);
hibernate的加锁模式:
LockMode.NONE:无锁机制。
LockMode.WRITE:Hibernate在Insert和Update记录的时候会自动获取。
LockMode.READ:Hibernate在读取记录的时候会自动获取。
这三种加锁模式是供hibernate内部使用的,与数据库加锁无关:
LockMode.UPGRADE:利用数据库的for update字句加锁。
在这里我们要注意的是:只有在查询开始之前(也就是hiernate生成sql语句之前)加锁,才会真正通过数据库的锁机制加锁处理。否则,数据已经通过不包含for updata子句的sql语句加载进来,所谓的数据库加锁也就无从谈起。
但是,从系统的性能上来考虑,对于单机或小系统而言,这并不成问题,然而如果是在网络上的系统,同时间会有许多联机,假设有数以百计或上千甚至更多的并发访问出现,我们该怎么办?如果等到数据库解锁我们再进行下面的操作,我们浪费的资源是多少?--这也就导致了乐观锁的产生。
2.乐观锁
乐观锁定(optimistic locking)则乐观的认为资料的存取很少发生同时存取的问题,因而不作数据库层次上的锁定,为了维护正确的数据,乐观锁定采用应用程序上的逻辑实现版本控制的方法。
乐观锁大多是基于数据版本(Version)记录机制实现。Hibernate在其数据访问引擎中内置了乐观锁实现,可以通过class描述符的optimistic-lock属性结合version描述符指定。optimistic-lock属性有如下可选取值:
1. none:无乐观锁
2. version:通过版本机制实现乐观锁
3. dirty:通过检查发生变动过的属性实现乐观锁
4. all:通过检查所有属性实现乐观锁