- 浏览: 932297 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (251)
- WebService (17)
- IBatis (22)
- Hibernate (1)
- SpringMVC - 基础篇 (32)
- Spring (15)
- Java (11)
- JVM及调优 - 基础篇 (4)
- 集群 (14)
- 数据库 (17)
- WebSphere (5)
- 多线程 (4)
- 集合、容器 (2)
- DB Pool (1)
- Power Designer (5)
- Maven基础 (5)
- JS (14)
- WEB 前端 (5)
- 实用小工具 (17)
- 社会、人 (2)
- 乱七八糟 (18)
- ASM&CGLIB - 基础篇 (12)
- 缓存 (1)
- 性能 (1)
- 设计之殇 (1)
- 分布式事务 (1)
- 单点登录 (11)
- 分布式 Session (4)
- Memcached - 基础篇 (6)
最新评论
-
一笑_奈何:
楼主写的还真行不错。
扫盲贴 - J2EE集群之JNDI集群实现 -
xuezhongyu01:
博主写的很详细,但最后还是没明白,最后调用BasicDataS ...
Spring中的destroy-method方法 -
Mr梁:
commons-fileupload.jar commons- ...
SpringMVC 中文件上传 MultipartResolver -
Eywa:
总结的很不错
ORACLE CASE WHEN 及 SELECT CASE WHEN的用法 -
TryRelax:
fastjson 比 jackson 好用吧?
Spring MVC Jackson DateFormat
一、锁(locking),为什么需要锁?
业务逻辑的实现过程中,往往需要保证数据访问的排他性。如在金融系统的日终结算处理中,我们希望针对某个 cut-off 时间点的数据进行处理,而不希望在结算进行过程中可能是几秒种,也可能是几个小时),数据再发生变化。此时,我们就需要通过一些机制来保证这些数据在某个操作过程中不会被外界修改,这样的机制,在这里,也就是所谓的“ 锁 ”,即给我们选定的目标数据上锁,使其无法被其他程序修改。
在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突。这就是著名的并发性问题。
典型的冲突有:
丢失更新:一个事务的更新覆盖了其它事务的更新结果,就是所谓的更新丢失。例如:用户A把值从6改为2,用户B把值从2改为6,则用户A丢失了他的更新。
脏读:当一个事务读取其它完成一半事务的记录时,就会发生脏读取。例如:用户A,B看到的值都是6,用户B把值改为2,用户A读到的值仍为6。
二、悲观锁(Pessimistic Locking)和 乐观锁(Optimistic Locking)
悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自
外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定
状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能
真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系
统不会修改数据)
乐观锁,相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库
性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
并发控制机制
悲观锁:假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。
乐观锁:假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。
乐观锁不能解决脏读的问题。
三、悲观锁 和 乐观锁 应用
乐观锁应用
1.使用自增长的整数表示数据版本号。更新时检查版本号是否一致,比如数据库中数据版本为6,更新提交时version=6+1,使用该version值(=7)与数据库version+1(=7)作比较,如果相等,则可以更新,如果不等则有可能其他程序已更新该记录,所以返回错误。
2.使用时间戳来实现.
注:对于以上两种方式,Hibernate自带实现方式:在使用乐观锁的字段前加annotation: @Version, Hibernate在更新时自动校验该字段。
悲观锁应用
需要使用数据库的锁机制,比如SQL SERVER 的TABLOCKX(排它表锁) 此选项被选中时,SQL Server 将在整个表上置排它锁直至该命令或事务结束。这将防止其他进程读取或修改表中的数据。
SqlServer中使用
Begin Tran
select top 1 @TrainNo=T_NO
from Train_ticket
with (UPDLOCK) where S_Flag=0
update Train_ticket
set T_Name=user,
T_Time=getdate(),
S_Flag=1
where T_NO=@TrainNo
commit
我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对此记录进行更新. 注意更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.
结论
在实际生产环境里边,如果并发量不大且不允许脏读,可以使用悲观锁解决并发问题;但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.
四、数据库并发控制,是选乐观锁还是悲观锁
实际生产环境里边,如果并发量不大,完全可以使用悲观锁定的方法,这种方法使用起来非常方便和简单。
但是如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以就要选择乐观锁定的方法。
悲观锁假定其他用户企图访问或者改变你正在访问、更改的对象的概率是很高的,因此在悲观锁的环境中,在你开始改变此对象之前就将该对象锁住,并且直到你提交了所作的更改之后才释放锁。悲观的缺陷是不论是页锁还是行锁,加锁的时间可能会很长,这样可能会长时间的限制其他用户的访问,也就是说悲观锁的并发访问性不好。
乐观锁则认为其他用户企图改变你正在更改的对象的概率是很小的,因此乐观锁直到你准备提交所作的更改时才将对象锁住,当你读取以及改变该对象时并不加锁。可见乐观锁加锁的时间要比悲观锁短,乐观锁可以用较大的锁粒度获得较好的并发访问性能。但是如果第二个用户恰好在第一个用户提交更改之前读取了该对象,那么当他完成了自己的更改进行提交时,数据库就会发现该对象已经变化了,这样,第二个用户不得不重新读取该对象并作出更改。这说明在乐观锁环境中,会增加并发用户读取对象的次数。
以版本控制系统为例,来说说两种最基本的并发性问题。
【丢失更新】
小张想修改源代码里面的a方法,正在她修改的同时,小李打开了这个文件,修改了b方法并且保存了文件,等小张修改完成后,保存文件,小李所做的修改就被覆盖了。
【不一致的读】
小张想要知道包里面一共有多少个类,包分了a,b两个子包。小张打开a包,看到了7个类。突然小张接到老婆打来的电话,在小张接电话的时候,小李往a包中加了2个类,b包中加了3个类(原先b包中是5个类)。
小张接完电话后再打开b包,看到了8个类,很自然得出结论:包中一共有15个类。
很遗憾,15个永远不是正确的答案。在小李修改前,正确答案是12(7+5),修改后是17(9+8)。这两个答案都是正确的,虽然有一个不是当前的。但15不对,因为小张读取的数据是不一致的。
小结:不一致读指你要读取两种数据,这两种数据都是正确的,但是在同一时刻两者并非都正确。
【隔离 和 不可变】
在企业应用中,解决并发冲突的两种常用手段是隔离和不可变。
只有当多个活动(进程或者线程)同时访问同一数据时才会引发并发问题。一种很自然的思路就是同一时刻只允许一个活动访问数据。如果小张打开了文件,就不允许其他人打开,或者其他人只能通过只读的方式打开副本,就可以解决这个问题。
隔离能够有效减少发生错误的可能。我们经常见到程序员陷入到并发问题的泥潭里,每一段代码写完都要考虑并发问题,这样太累了。我们可以利用隔离技术创建出隔离区域,当程序进入隔离区域时不用关心并发问题。好的并发性设计就是创造这样的一些隔离区域,并保证代码尽可能的运行在其中。
另一种思路:只有当你需要修改共享的数据时才可能引发并发性问题,所以我们可以将要共享的数据制作为“不可变”的,以避免并发性问题。当然我们不可能将所有的数据都做成不可变的,但如果一些数据是不可变的,对它们进行并发操作时我们就可以放松自己的神经了。
【乐观并发控制、悲观并发控制】
如果数据是可变的,并且无法隔离呢?这种情况下最常用的两种控制就是乐观并发控制和悲观并发控制。
假设小张和小李想要同时修改同一个文件。如果使用乐观锁,俩人都能打开文件进行修改,如果小张先提交了内容,没有问题,他所做的改变会保存到服务器上。但小李提交时就会遇到麻烦,版本控制服务器会检测出两种修改的冲突,小李的提交会被具体,并由小李决定该如何处理这种情况(对于绝大部分版本控制软件来说,会读取并标识出小张做的改变,然后由小李决定是否合并)。
如果使用的是悲观锁,小张先检出(check out)文件,那么小李就无法再次检出同一文件,直到小张提交了他的改变。
建议你将乐观锁想成一种检测冲突的手段,而悲观锁是一种避免冲突的手段(严格来说,乐观锁其实不能称之为“锁”,但是这个名字已经流传开了,那就继续使用吧)。一些老的版本控制系统,比如VSS 6.0使用的是悲观锁的机制。而现代的版本控制系统一般两种都支持,默认使用乐观锁。
两种锁各有优缺点。。。这段懒的翻译了,很明显看出,乐观锁可以提高并发访问的效率,但是如果出现了冲突只能向上抛出,然后重来一遍;悲观锁可以避免冲突的发生,但是会降低效率。
选择使用那一种锁取决于访问频率和一旦产生冲突的严重性。如果系统被并发访问的概率很低,或者冲突发生后的后果不太严重(所谓后果应该指被检测到冲突的提交会失败,必须重来一次),可以使用乐观锁,否则使用悲观锁。
【我再补充两句】
我们经常会在访问数据库的时候用到锁,怎么实现乐观锁和悲观锁呢?以Hibernate为例,可以通过为记录添加版本或时间戳字段来实现乐观锁。可以用session.Lock()锁定对象来实现悲观锁(本质上就是执行了SELECT * FROM t FOR UPDATE语句)。
另一个高并发控制解决方案乐观并发控制和悲观并发控制总结概述:
我们可以使用两种形式的并发控制策略:乐观并发控制和悲观并发控制。
假设martin和David同时都要编辑Customer文件。如果使用乐观锁策略,他们两个人都能得到一份文件的Copy,并且可以自由编辑文件。假设David第一个完成了工作,那么他可以毫无困难地更新他的修改。但是,当Martin想要提交他的修改时,并发控制策略就会开始起作用。源代码控制系统会检测到在Martin的修改与David的修改之间存在着冲突,因而拒绝Martin的提交,并由Martin负责指出怎样处理这种情况。如果使用悲观锁策略,只要有人先取出文件,其他人就不能对该文件进行编辑。因此,假如是Martin先取了文件,那么David就只能在Martin完成任务并提交之后才能对该文件进行操作。
如果把乐观锁看作是关于冲突检测的,那么悲观锁就是关于冲突避免的。在实际应用的源代码控制系统中,这两种策略都可以被使用,但是现在大多数源代码开发者更倾向于使用乐观锁策略。(有一种很有道理的说法:乐观锁并不是真正的锁定,但是这种叫法很方便并且广泛流传,以至于不容忽略。)
这两种策略各有优缺点。悲观锁的问题是减少了并发的程序。当Martin正对一个被他加锁的文件进行编辑的时候,其它人只能等着。使用过悲观的源代码控制人都知道这是一种多么令人丧气的事情。对于企业数据,情况经常会变得更加糟糕,只要有人在编辑,其他人就无法进行读取,更加说进行编辑了。
乐观锁策略则允许人们更自由一些,因为只有在提交的时候才有可能遇到阻碍。该策略的问题在于当冲突的时候会发生什么样的事情呢?事实上,David之后的所有人在提交的时候都必须读取David修改过的那个版本,并指出怎样合并自己和David的修改,然后再提交一个重新修改过的最新版本。有了源代码控制系统,这样做并不会有什么麻烦。在许多场合下,源代码控制系统确实能够自动进行合并操作,甚至在无法自动合并的时候,也能让使用都很容易看出不同文件版本之间的差别。但是,业务数据通常都是很难被自动合并的,所以经常只能扔掉原来的东西,然后从头开始。
在乐观锁和悲观锁之间进行选择的标准是:冲突的频率与严重性。如果冲突很少,或者冲突的后果不会很严重,那么通常情况下应该选择乐观锁,因为它能得到更好的并发性,而且更容易实现。但是,如果冲突的结果对于用户来说痛苦的,那么就需要使用悲观策略。
乐观锁的局限是:只能在提交数据时才发现业务事务将要失败,而且在某些情况下,发现失败太迟的代价会很大。用户可能花了一个小时的时间输入一份租约的详细信息,错误太多会让用户对系统失去信心。另一个方法是使用悲观锁,它可以尽早地发现错误,但理难以编程实现,而且会降低系统的灵活性。
(注:以上是对并发控制中的乐观锁策略和悲观锁策略概念及解决思路的文字描述,下面我将对项目中具体怎么实现乐观锁策略及悲观锁策略进行描述。)
乐观锁策略实现方法:
就是用C#中或SQL中的事务来实现数据操作不成功就回滚,个人感觉火车站卖票系统也是这样操作的,我们看到显示屏上有少量剩余票,但我们去买又打不出来。
悲观锁策略实现方法:
1、普通的aspx页面,当用户点提交后,直接将提交及相关按钮的enabel改为false,直到提交事件完成后,再改回来。另外在数据层那一块,每次提交数据更改时,都需要判断数据以前的状态是否改变,以防止有并发改变的情况出现。
2、jquery中,在jquery中,可以设置一个全局变量,提交时,先判断全局变量状态,如不允许提交则直接返回,如允许提交时,则先将全局变量置为“不允许提交”,后开始提交,提交完成后,在jquery的post方法的callback方法中,再将全局变量改为“允许提交”。
3、弹出式窗口修改页面,则用模态方式弹出,如web页面中,可用window.showModalDialog()来实现模态方式打开修改页面,来确保始终只有一个修改页面被打开。(这是从数据操作页面处就悲观锁定了数据,而不是在数据库里面悲观锁定)
参考网络文章!
发表评论
-
ORA-12519: TNS:no appropriate service handler found 解决
2013-07-11 10:59 1065java.sql.SQLException: Listene ... -
数据库模糊搜索时,关键字中处理特殊字符(%,_)
2013-02-26 14:02 1774数据库模糊搜索时, ... -
关系型数据库(Oracle)性能优化(三)
2012-02-26 15:43 987关系型数据库性能优化总结 对于web应 ... -
关系型数据库(Oracle)性能优化(二)
2012-02-26 15:24 865调整数据库结构的设计 这一部分在开发信息系统之前完 ... -
关系型数据库(Oracle)性能优化(一)
2012-02-26 15:03 1187为了保证Oracle数据库运行在最佳的性能状态下,在信 ... -
ORACLE的隔离级别
2012-02-13 21:41 1027一、隔离级别(isolation level) ... -
Oracle 常用函数
2011-10-15 14:24 1759一、函数的分类 SQL函数一般分为两种 ... -
Oracle 分组与分组函数
2011-10-15 14:02 1695一、分组: 分组函数可以对行集进行操作,并且为每组给 ... -
ORACLE CASE WHEN 及 SELECT CASE WHEN的用法
2011-10-15 13:07 120609Case具有两种格式。简单Case函数和Case搜 ... -
Oracle用Start with...Connect By子句递归查询
2011-10-09 17:27 1020ORACLE 提供了一个有趣的功能 connect b ... -
Oracle行列互换 横表和纵表
2011-08-19 14:28 1465转载http://xace.iteye.com/blog ... -
Oracle 横表、纵表一点记录
2011-08-19 14:07 3938横表就是普通的建表方式,如一个表结构为: 主键、字段1、字段2 ... -
SQL 乱七八糟
2011-07-18 21:10 8191、 两个日期间的天数: select flo ... -
Oracle 中 MERGE
2011-07-18 21:02 1001一、概述 MERGE语句是Oracle9i新增的 ... -
关于Oracle错误:动态执行表不可访问,本会话自动统计被禁止,关闭自动统计之后的问题
2011-07-10 23:23 4120最近使用PL/SQL,但是每次第一次打开表的时候会提示&quo ... -
数据库查询优化方案(处理上百万级记录如何提高处理查询速度)
2011-05-31 21:11 9821.对查询进行优化,应 ...
相关推荐
主要分为两种类型:乐观锁(Optimistic Locking)和悲观锁(Pessimistic Locking)。 **悲观锁(Pessimistic Locking)** 悲观锁假设数据在任何时候都可能发生并发冲突,因此在数据读取时就对其进行锁定,确保在...
一、悲观锁(Pessimistic Locking) 悲观锁是一种预防并发访问的机制,Hibernate 通过对数据库的锁定来实现。悲观锁假定任何时刻存取数据时,都可能有另一个客户也正在存取同一笔数据,因此对数据采取了数据库层次...
#### 一、悲观锁(Pessimistic Locking) 悲观锁是一种基于对数据安全性的保守态度而设计的锁机制。它假设数据在处理过程中很可能被外界修改,因此在整个数据处理过程中都会将数据锁定,以确保数据的一致性和完整性...
#### 二、悲观锁(Pessimistic Locking) ##### 2.1 定义 悲观锁是一种较为传统的锁机制,它假定并发冲突的可能性很高,因此在整个数据处理过程中都会锁定数据。这种机制能够有效防止数据被其他事务修改,但同时也...
本文主要讨论的是Hibernate框架中两种锁机制的使用:乐观锁和悲观锁。 首先,让我们深入理解悲观锁(Pessimistic Locking)。悲观锁正如其名字所示,假设并发环境中数据会被频繁修改,所以在整个数据处理过程中,它...
### Hibernate的乐观锁和悲观锁 #### 一、引言 在软件开发中,尤其是在涉及大量并发操作的应用场景下,确保数据的一致性和完整性是非常重要的。对于基于Java Web的应用而言,Hibernate作为一款流行的ORM框架,提供...
乐观锁和悲观锁是两种常见的并发控制策略,对于理解并优化多线程环境下的数据库操作至关重要。以下是对这两种锁机制的详细解释。 **乐观锁(Optimistic Locking)** 乐观锁假设在大多数情况下,数据不会发生冲突,...
悲观锁(Pessimistic Locking)是一种保守的锁策略,它假设在数据处理过程中,其他线程很可能会修改数据,因此在获取数据时便立即对资源进行加锁,这样其他线程想要访问同一资源就必须等待锁的释放。在关系型数据库中...
SpringBoot整合MyBatis实现乐观锁和悲观锁的示例 在本文中,我们将学习如何使用SpringBoot和MyBatis来实现乐观锁和悲观锁。我们将通过示例代码来介绍这两种锁的实现方式,帮助读者更好地理解和使用它们。 一、悲观...
为了解决这些问题,Java 提供了多种锁机制,其中最常见的就是乐观锁和悲观锁。 悲观锁(Pessimistic Locking)是一种传统的锁机制,它总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的...
为了解决这些问题,通常会采用两种锁机制——乐观锁和悲观锁。 1. 乐观锁(Optimistic Locking)乐观锁假设并发冲突较少,因此在数据读取时不加锁,而在更新时检查数据是否已被其他事务修改。例如,Hibernate通过...
8. **乐观锁(Optimistic Locking)与悲观锁(Pessimistic Locking)**:乐观锁假设很少发生并发冲突,只在提交时检查是否发生冲突;悲观锁则在读取数据时就获取锁,防止其他事务修改。 9. **行锁升级(Lock ...
7. **悲观锁(Pessimistic Locking)**:在进行操作前先锁定数据,防止其他事务修改,保证数据一致性。 8. **间隙锁(Gap Locks)**:InnoDB存储引擎的一种特性,防止其他事务在已锁定的行之间的间隙插入新行,防止...
6. **事务与并发控制**:理解事务(TRANSACTION)的概念,学习使用BEGIN、COMMIT和ROLLBACK语句管理事务,以及了解并发控制机制,如锁定(Locking)、乐观锁(Optimistic Locking)和悲观锁(Pessimistic Locking)...
NHibernate 支持多种并发策略,如 Optimistic Locking(乐观锁)和 Pessimistic Locking(悲观锁)。乐观锁通常基于版本号或时间戳,假设大多数事务不会冲突,只有在提交时才检查冲突。悲观锁则在读取数据时立即锁定...
对于并发控制,Hibernate 支持 Optimistic Locking(乐观锁)和 Pessimistic Locking(悲观锁)。乐观锁通过版本号或者时间戳来确保数据的一致性,悲观锁则在读取数据时立即进行锁定,防止其他事务修改。3. 拦截器...