数据库锁
一、概念
1、排它锁和共享锁
在数据库中有两种基本的锁类型:排它锁(Exclusive
Locks,即X锁)和共享锁(Share Locks,即S锁)。
当数据对象被加上排它锁时,其他的事务不能对它读取和修改。
加了共享锁的数据对象可以被其他事务读取,但不能修改。
数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。
2、表级锁和行级锁
DML锁的目的在于保证并发情况下的数据完整性,主要包括TM锁和TX锁,其中TM锁称为表级锁,TX锁称为事务锁或行级锁。
当Oracle执行DML语句时,系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后,系统再自动申请TX类型的锁,并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX锁相容性时就不用再逐行检查锁标志,而只需检查TM锁模式的相容性即可,大大提高了系统的效率。
3、活锁和死锁
活锁:当事务T1封锁数据R,事务T2请求数据R于是T2等待。T1释放了R上的封锁,系统首先批准了T3的请求,T2继续等待,之后系统批准了T4的请求……依此类推,T2可能永久等待。这种现象称为活锁。
死锁:是指两个以上事务分别请求封锁对方已经封锁的数据,导致长期等待而无法继续进行下去的现象叫死锁。
二、数据库脏读、不可重复读和幻读
锁就是防止其他事务访问指定的资源的手段。锁是实现并发控制的主要方法,是多个用户能够同时操纵同一个数据库中的数据而不发生数据不一致现象的重要保障。 一般来说,锁可以防止脏读、不可重复读和幻觉读。
1、事务并发产生的问题
1)脏读:一个事务读取到了另外一个事务没有提交的数据
事务1:更新一条数据
------------->事务2:读取事务1更新的记录
事务1:调用commit进行提交
--此时事务2读取到的数据是保存在数据库内存中的数据,称为脏读。
--读到的数据为脏数据
详细解释:
脏读就是指:当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,
这时,另外一个事务也访问这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,
那么另外一个事务读到的这个数据是脏数据,依据脏数据所做的操作可能是不正确的。
2)不可重复读:在同一事务中,两次读取同一数据,得到内容不同
事务1:查询一条记录
-------------->事务2:更新事务1查询的记录
-------------->事务2:调用commit进行提交
事务1:再次查询上次的记录
--此时事务1对同一数据查询了两次,可得到的内容不同,称为不可重复读
3)幻读:同一事务中,用同样的操作读取两次,得到的记录数不相同
事务1:查询表中所有记录
-------------->事务2:插入一条记录
-------------->事务2:调用commit进行提交
事务1:再次查询表中所有记录
--此时事务1两次查询到的记录是不一样的,称为幻读
详细解释:
幻读是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,
这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表
中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,
就好象发生了幻觉一样。
三、处理以上隔离级别的问题
采用如下方式:
1、事务隔离五种级别
- TRANSACTION_NONE 不使用事务。
- TRANSACTIONREADUNCOMMITTED 允许脏读。
- TRANSACTIONREADCOMMITTED
防止脏读,最常用的隔离级别,并且是大多数数据库的默认隔离级别
- TRANSACTIONREPEATABLEREAD 可以防止脏读和不可重复读,
- TRANSACTION_SERIALIZABLE 可以防止脏读,不可重复读取和幻读,(事务串行化)会降低数据库的效率
以上的五个事务隔离级别都是在Connection接口中定义的静态常量,
使用setTransactionIsolation(int level) 方法可以设置事务隔离级别。
如:con.setTransactionIsolation(Connection.REPEATABLE_READ);
注意:事务的隔离级别受到数据库的限制,不同的数据库支持的的隔离级别不一定相同
2、具体原理
1)脏读:
修改时加排他锁,直到事务提交后才释放,读取时加共享锁,读取完释放事务1读取数据时加上共享锁后(这
样在事务1读取数据的过程中,其他事务就不会修改该数据),不允许任何事物操作该数据,只能读取,之后1如果有更新操作,那么会转换为排他锁,其他事务更
无权参与进来读写,这样就防止了脏读问题。
但是当事务1读取数据过程中,有可能其他事务也读取了该数据,读取完毕后共享锁释放,此时事务1修改数据,修改 完毕提交事务,其他事务再次读取数据时候发现数据不一致,就会出现不可重复读问题,所以这样不能够避免不可重复读问题。
2)不可重复读:
读取数据时加共享锁,写数据时加排他锁,都是事务提交才释放锁。读取时候不允许其他事物修改该数据,不管数据在事务过程中读取多少次,数据都是一致的,避免了不可重复读问题
3)幻读问题:
采用的是范围锁RangeS
RangeS_S模式,锁定检索范围为只读,这样就避免了幻影读问题。
3、举例说明
在这里有个描述范围锁的文章:
当执行不同的隔离级别时,可能会发生各种各样不同的问题。下面对它们进行总结并举例说明:
1)幻读 :
幻读发生在当两个完全相同的查询执行时,第二次查询所返回的结果集跟第一个查询不相同。
发生的情况:没有范围锁。
例子:
如何避免:实行序列化隔离模式,在任何一个低级别的隔离中都可能会发生。
2)不可重复读:
在基于锁的并行控制方法中,如果在执行select时不添加读锁,就会发生不可重复读问题。
在多版本并行控制机制中,当一个遇到提交冲突的事务需要回退但却被释放时,会发生不可重复读问题。
在上面这个例子中,事务2提交成功,它所做的修改已经可见。然而,事务1已经读取了一个其它的值。在序列化和可重复读的隔离级别中,数据库管理系统会返回旧值,即在被事务2修改之前的值。在提交读和未提交读隔离级别下,可能会返回被更新的值,这就是“不可重复读”。
有两个策略可以防止这个问题的发生:
推迟事务2的执行,直至事务1提交或者回退。这种策略在使用锁时应用。
而在多版本并行控制中,事务2可以被先提交。而事务1,继续执行在旧版本的数据上。当事务1终于尝试提交时,数据库会检验它的结果是否和事务1、事务2顺序执行时一样。如果是,则事务1提交成功。如果不是,事务1会被回退。
3)脏读:
脏读发生在一个事务A读取了被另一个事务B修改,但是还未提交的数据。假如B回退,则事务A读取的是无效的数据。这跟不可重复读类似,但是第二个事务不需要执行提交。
四、参考资料
1、那什么是乐观锁,什么是悲观锁。
悲观锁:需要使用数据库的锁机制,如数据库有表级排它锁,有行级排它锁。
假定一切操作都可能发现并发冲突,所以采取悲观态度。通过加锁,屏蔽一切可能违反数据完整性的操作
比方select * from table for update; 就是表锁,
select * from table where x = 1 for update; 就是行锁。
当使用for update后,其它会话还是可以执行select操作,但无法执行select xx
for update操作,只有当前会话commit后,其它for
update操作才会被执行。
典型例子可以参考quartz集群的锁机制:http://blog.itpub.net/11627468/viewspace-1764753/
当然,此时也不可以update,update需要等select xx for update
所在会话commit后才能执行。
注:mysql需要设置autocommit=0
乐观锁:其实不是真实的去锁住记录不让访问,或者不让更新。
假定操作很少发生冲突,一般对于读多写少的情况。只在提交操作时检查是否违反数据完整性。[1]
乐观锁不能解决脏读的问题。
可以通过版本号是否比上个版本号或者时间戳来实现。
对于冲突检测后的处理,需要业务逻辑去处理。
2、参考的网址
以上悲观锁和乐内容参考:
http://www.cnblogs.com/guyufei/archive/2011/01/10/1931632.html
spring锁实现参数:
http://blog.itpub.net/12158104/viewspace-374745
关于隔离级别可以参考:
http://blog.itpub.net/11627468/viewspace-1793036/
关于数据库的锁可以参考:
http://zhidao.baidu.com/link?url=zRnaslJ8INtEviT--BzrT2bMOqf4LJQzL-NQg2ECu6l-s-xPHi11bBlNjN2_zyNrwd9M0ZnbelQntmfYPB0ifq