本文主要是介绍关于数据库中的事务(transaction),程序员必须记住的三点,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
关于数据库中的事务(transaction),程序员必须记住的三点
1. 对于程序员来说,理解事务以及并发事务的概念非常重要。下面先通过银行的转帐业务以及演示案例帮助大家建立并深入理解事务。
以下这段代码模拟我们在银行要完成的转账业务。研读以下代码,判断哪些SQL语句必须看作一个逻辑单元,即这些语句要执行成功都得成功;若有一条语句不能成功执行,其他语句也不允许成功。为什么会有这样的要求?
create table b_account(
id number(19) constraint b_account_id_pk primary key,
banlance number);
insert into b_account values (1111,4000);
insert into b_account values (2222,100);
--从帐户1111转3000到帐户2222:
update b_account set balance = balance - 3000
where id = 1111;
update b_account set balance = balance + 3000
where id = 2222;
这是因为:如果不看成一个逻辑单元,账就不平了,即:要保证收支平衡。
那么在数据库中怎样表示一些DML语句是一个逻辑单元——通过将他们定义成事务来实现。
我们重新审视一下数据库中的数据是怎样被改变的?
首先程序员通过一个应用程序(系统提供如sqlplus、sql developer,或同学们自己编写的)跟数据库建连接,连接成功的标志是ORACLE SERVER端多了一个进程称之为sever process(ORACLEtarena),同时系统会创建一个会话session,客户端与oracle的交互都在这个会话环境中进行,即以前所说 SQL语句的运行环境,可以通过alter session修改该环境的设置。从现在开始,更准确地说应该是事务的运行环境。
当有很多用户都要操作数据库中的数据时,ORACLE SERVER就表现为当前有很多个session,每个session当前有一个活动事务,当一个事务结束,新的事务又开始。
对于这一类应用系统,有一个明确的定义称为OLTP(online transaction processing 联机事务处理)系统,表现为同时有很多个session,每个session上的事务都很小。即有大量的并发小事务同时发生。
2. 并发操作案例:
案例一:
--创建表test,插入如数据后提交:
create table test(
c1 number,
c2 number);
insert into test values (1,1);
insert into test values (2,2);
insert into test values (3,3);
commit;
session1:
--向test表中插入数据:
insert into test values (4,4);
insert into test values (5,5);
--查询test表:
select * from test;
--结果:
C1 C2
---------- ----------
1 1
2 2
3 3
4 4
5 5
session2:
--查询test表:
select * from test;
--结果:
C1 C2
---------- ----------
1 1
2 2
3 3
session2中看不到4,4和5,5记录的原因:事务的隔离级别是read committed,每个session可以看到的数据是已经提交了的数据和本session中正在修改的数据。session1中的操作没有提交(commmit),所以session2中看不到session1中向test表中插入的4,4和5,5。
程序员需要记住的第一点,我们给数据库送去的是事务,而不是SQL语句,最后必须有commit或rollback语句,否则其他session看不见你修改的数据。
如果将session1中的操作提交:
session1:
commit;
案例二:
然后在其他session中查询:
session1,session2,session3:
select * from test;
--结果:
C1 C2
---------- ----------
1 1
2 2
3 3
4 4
5 5
在session1中对test表进行更新(update)操作:
session1:
update test set c1 = 11
where c2 = 1;
--结果:
1 row updated.
在session2中对test表进行更新(update)操作:
session2:
update test set c1 = 111
where c1 = 1;
--结果:
--光标不停闪烁....
现象是提示符始终不出现,好像没有反应。
session3:
update test set c1 = 22
where c2 = 2;
--结果:
1 row updated.
现象是session1和session3都完成了对记录的修改,session2始终在等待。session2和session3所不同的是session2和session1修改的是同一条记录,而session3修改的是另一条记录。也就是当多个session修改同一条记录时,后一个session会等待。
在并发操作时,怎样保证每一个session可以以一致的方式读取并修改数据。
表 - 1DML锁

session2等待的原因是想在记录上加行级排他锁,但被session1占用的,只好等待,一直等到session1释放。当事务结束,即commit或rollback之后,这些DML语句加的锁就都释放了。
session1:
commit;
session2:
update test set c1 = 111
where c1 = 1;
--结果:
0 rows updated.
session3:
drop table test purge;
--结果:
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified
错误信息:资源忙(test表上有DML操作),加锁的方式是NOWAIT,所以不会等待。
session2还没commit,因此test表上还有表级共享锁。执行DDL操作时,要在表上加DDL排他锁而不能,此时并不等待,而报错放弃。
程序员需要记住的第二点,我们给数据库送去的是事务,而不是SQL语句,最后必须有commit或rollback语句,否则DML锁不释放会阻塞其他session的操作。
案例三:
--创建表test:
create table test(
c1 number,
c2 number);
--向表中插入数据并提交:
insert into test values (1,1);
insert into test values (2,2);
insert into test values (3,3);
commit;
--删除test表中c2列为3的一行:
delete from test where c2 = 3;
--结果:
1 rows deleted.
--更新test表中c1列为1的一行:
update test set c2 = 11 where c1 = 1;
--结果:
1 rows updated.
--再次向test表中插入数据:
insert into test values (4,4);
--结果:
1 rows inserted.
--查询test表:
select * from test;
--结果:
C1 C2
---------- ----------
1 11
2 2
4 4
--回滚:
rollback;
--查询test
select * from test;
--结果:
C1 C2
---------- ----------
1 1
2 2
3 3
--原因:回滚(rollback)后,test表恢复到上一次提交时的状态,好像从未发生过提交后的操作。
rollback是对事务的回滚,好像它从未发生,数据恢复到该事务开始之前的状态。
数据之所以可以恢复,得益于数据库的undo segment(回滚段),会将操作之前的数据放在那里,当commit或rollback时,事务所占用的空间被释放,可以给其他事务使用。
程序员需要记住的第三点,我们给数据库送去的是事务,而不是SQL语句,最后必须有commit或rollback语句,否则占用的回滚段空间不释放,有可能导致某些session的DML语句由于申请不到回滚空间而报错。
用了这么多篇幅为大家阐述了关于数据库中的事务,程序员必须记住的三点,我不知道对大家有多大的帮助,但是我觉得很重要,而且薛海璐老师也重点强调了,在这儿指出来无非就是引起大家的重视!我觉得一条commit语句的重要性就像我们在编java程序时时不时要做的一个动作——Ctrl+S一样重要,有时候我们编的一个项目不断报错,花了半天时间但就是找不到错误的所在,结果到头来却是其中的一两个类没有保存!!!
千里之堤,溃于蚁穴!往往一个不经意的小错误就可以铸成大错!也许我们平时多留心一点,就可以省掉很多麻烦。
细节决定成败,确实是受用终生的一句话,望大家共勉!
这篇关于关于数据库中的事务(transaction),程序员必须记住的三点的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!