DB2缺省的事务及并发锁机制
来源:互联网 发布:啊哈算法2出了吗 编辑:程序博客网 时间:2024/05/21 18:30
今天有点时间,试验了一下DB2的并发锁机制,结果,和MSSQL的差不多:
1、DB2的缺省行为,事务以可执行的SQL开始,以COMMIT或ROLLBACK结束;
2、DB2缺省是否提交,以工具的不同而不同,这也是DB2的特点,对外界环境依赖比较明显,比如:用户认证就是,依赖操作系统或第三方认证。
3、今天我的试验过程是这样:
(1)先启动DB2CLP,db2cmd->db2
(2)连接TEST数据库,connect to test
(3)创建一个试验表,create table test(id int,aa varchar(10))
(4)验证表结构,describe table test
(5)插入两行数据,insert into test values(1,'aaaa')
insert into test values(2,'bbbb')
(6)验证数据,select * from test
h 历史命令;
r n 运行第n条命令;
e n编辑第n条命令;
(7)update test set aa='cccc' where id=1
(8)启动另一个DB2CLP,update test set aa='dddd' where id=1,结果没什么阻塞,大为震惊,都说ORACLE的锁独步天下,没想到DB2的锁也是独步天下啊。回头觉得不对劲,查了一下
DB2的文档,结果DB2是否自动提交依赖于接口或工具,那么DB2CLP的这个选项缺省是什么呢?
(9)DB2CLP下查各种命令选项,list command options;
(10)结果选项c 缺省为ON,打开的,意味着在DB2CLP中,缺省对SQL命令是自动提交的。
(11)把C 选项改为OFF,update command options using c off,注意在每个DB2CLP中都要改,因为这个命令只会影响到当前连接。
(12)修改完三个DB2CLP连接中的C 选项后,开始试验;
(13)第一个DB2CLP中,update test set aa='eeee' where id=1;
第二个DB2CLP中,update test set aa='ffff' where id=1;
结果阻塞;然后在第三个DB2CLP中,update test set aa='GGGG' where id=2;
也是阻塞,说明db2不但阻塞了同行数据的修改,这是正常的,而且也阻塞了不同行但在一个
page页中的行的修改,看来它得锁模型也是和MSSQL一样,属于悲观模型。
这段时间把各种系统的锁模型进行了比较,结果发现,DB2和MSSQL比较相似的,之前,我对MSSQL的锁进行了更进一步的跟踪,发现MSSQL对未提交事务涉及的表是加表级锁的,这会阻塞其他事务对该事务涉及表的修改操作。同时,也会阻塞其他事务的读操作。
而对于ORACLE和MYSQL来说,是不会产生这种表或块级阻塞的,主要还是因为锁模型的不同,主要还是观念的原因吧,或者说是乐观和悲观的原因。谈不上谁好谁坏,大家只看到了并发度,而没看到乐观锁会给应用带来的坏处,就一味的说悲观锁不好,不可否认ORACLE等系统的乐观锁会带来系统性能上的好处,让大家用着会舒服,可应用上的处理就会麻烦些,这也是DB2,MSSQL始终不改变这点的原因,观念不同而已。
1、DB2的缺省行为,事务以可执行的SQL开始,以COMMIT或ROLLBACK结束;
2、DB2缺省是否提交,以工具的不同而不同,这也是DB2的特点,对外界环境依赖比较明显,比如:用户认证就是,依赖操作系统或第三方认证。
3、今天我的试验过程是这样:
(1)先启动DB2CLP,db2cmd->db2
(2)连接TEST数据库,connect to test
(3)创建一个试验表,create table test(id int,aa varchar(10))
(4)验证表结构,describe table test
(5)插入两行数据,insert into test values(1,'aaaa')
insert into test values(2,'bbbb')
(6)验证数据,select * from test
h 历史命令;
r n 运行第n条命令;
e n编辑第n条命令;
(7)update test set aa='cccc' where id=1
(8)启动另一个DB2CLP,update test set aa='dddd' where id=1,结果没什么阻塞,大为震惊,都说ORACLE的锁独步天下,没想到DB2的锁也是独步天下啊。回头觉得不对劲,查了一下
DB2的文档,结果DB2是否自动提交依赖于接口或工具,那么DB2CLP的这个选项缺省是什么呢?
(9)DB2CLP下查各种命令选项,list command options;
(10)结果选项c 缺省为ON,打开的,意味着在DB2CLP中,缺省对SQL命令是自动提交的。
(11)把C 选项改为OFF,update command options using c off,注意在每个DB2CLP中都要改,因为这个命令只会影响到当前连接。
(12)修改完三个DB2CLP连接中的C 选项后,开始试验;
(13)第一个DB2CLP中,update test set aa='eeee' where id=1;
第二个DB2CLP中,update test set aa='ffff' where id=1;
结果阻塞;然后在第三个DB2CLP中,update test set aa='GGGG' where id=2;
也是阻塞,说明db2不但阻塞了同行数据的修改,这是正常的,而且也阻塞了不同行但在一个
page页中的行的修改,看来它得锁模型也是和MSSQL一样,属于悲观模型。
这段时间把各种系统的锁模型进行了比较,结果发现,DB2和MSSQL比较相似的,之前,我对MSSQL的锁进行了更进一步的跟踪,发现MSSQL对未提交事务涉及的表是加表级锁的,这会阻塞其他事务对该事务涉及表的修改操作。同时,也会阻塞其他事务的读操作。
而对于ORACLE和MYSQL来说,是不会产生这种表或块级阻塞的,主要还是因为锁模型的不同,主要还是观念的原因吧,或者说是乐观和悲观的原因。谈不上谁好谁坏,大家只看到了并发度,而没看到乐观锁会给应用带来的坏处,就一味的说悲观锁不好,不可否认ORACLE等系统的乐观锁会带来系统性能上的好处,让大家用着会舒服,可应用上的处理就会麻烦些,这也是DB2,MSSQL始终不改变这点的原因,观念不同而已。
0 0
- DB2缺省的事务及并发锁机制
- DB2 事务及锁
- 数据库并发机制及事务隔离机制
- MySQL的事务隔离及锁机制
- informix的事务、并发控制、锁机制、隔离级别
- 数据库并发事务控制四:postgresql数据库的锁机制
- Informix的事务、并发控制、锁机制、隔离级别
- Informix的事务、并发控制、锁机制、隔离级别
- 事务并发控制和锁机制
- Mysql事务,并发问题,锁机制
- Mysql事务,并发问题,锁机制
- Mysql事务,并发问题,锁机制
- 事务并发机制
- hibernate事务并发机制
- 数据库事务及锁机制
- 事务并发的问题及处理
- DB2并发性和事务隔离级别
- 改变 Grails 的缺省事务行为
- php中系统变量
- CentOS 6.3下Samba服务器的安装与配置
- 枚举
- 数据结构——线性表
- Linux 中出现的-bash: syntax error near unexpected token `('错误-------终端中无法识别“()”问题解决
- DB2缺省的事务及并发锁机制
- onItemClick方法中的四个参数
- MIPI RFFE
- 关于用户登录时需要选择不同按钮的解决
- db file scattered read
- html常用标签大全--附使用方法
- 20个超实用的JavaScript技巧及最佳实践
- Unity3D 4.x.x for Mac 破解步骤
- Java 读取 C++写入的二进制数据