最近一个项目中发现了一个严重的问题，就是系统上线的回归测试时发现系统存在锁表的问题，直接导致事务不能结束（提交货品回滚），最终造成连接得不到释放，进而当开启的连接超过连接池的最大连接数时，系统将提示获取不到连接，从而崩溃！
一般的系统采用的都是Spring提供的声明式事务。而我们系统由于历史遗留问题，采用了offbiz的基于模型配置的架构体系，此套体系中事务的开启以及关闭都是通过编程式事务完成。编程式事务在事务范围控制方面比较灵活，但是在灵活的同时也存在潜在的风险。如果事务开启后没有正常结束，那么事务也就会一直占用连接而得不到释放。虽然可以通过设置事务超时值从而在事务超时杀掉事务释放连接，这种方式个人觉得还是存在一定得不可控性。所以对于编程式事务的使用，还应该注意一下几点：
第一点，有开有关：事务管理层有事务开启必须有事务关闭，可以通过设置事务旗标在finally中进行事务管理；示意性代码如下：
第二点，单一出口：即一个方法的renturn只有一处，异常情况通过throw 抛出，确保最外层事务管理层能够通过捕获到得异常控制事务状态（提交或回滚）。
第三点，设置事务超时：事务执行超过指定时间，强制杀掉事务，关闭连接，从而确保其他业务不会应为该事务锁定相关业务表而阻塞而导致恶性循环。
如果怀疑表被锁了，或者事务未被正常关闭，在Oracle数据库中我们可以通过以下语句进行查询获取相关信息：
Sql代码
- select t2.username,
- t2.sid,
- t2.serial#,
- t3.object_name,
- t2.OSUSER,
- t2.MACHINE,
- t2.PROGRAM,
- t2.LOGON_TIME,
- t2.COMMAND,
- t2.LOCKWAIT,
- t2.SADDR,
- t2.PADDR,
- t2.TADDR,
- t2.SQL_ADDRESS,
- t1.LOCKED_MODE
- from v$locked_object t1, v$session t2, dba_objects t3
- where t1.session_id = t2.sid
- and t1.object_id = t3.object_id
- order by t2.logon_time;
select t2.username, t2.sid, t2.serial#, t3.object_name, t2.OSUSER, t2.MACHINE, t2.PROGRAM, t2.LOGON_TIME, t2.COMMAND, t2.LOCKWAIT, t2.SADDR, t2.PADDR, t2.TADDR, t2.SQL_ADDRESS, t1.LOCKED_MODE from v$locked_object t1, v$session t2, dba_objects t3 where t1.session_id = t2.sid and t1.object_id = t3.object_id order by t2.logon_time;
大家发现，上面这条SQL语句用到了Oracle的两个视图和一个表，分别是v$locked_object、v$session、dba_objects：
v$locked_object 视图中记录了所有session中的所有被锁定的对象信息。
v$session 视图记录了所有session的相关信息。
dba_objects 为oracle用户对象及系统对象的集合，通过关联这张表能够获取被锁定对象的详细信息。
v$locked_object中的LOCKED_MODE字段表示锁的模式，oracle中锁的模式有如下几种：
0：none
1：null 空
2：Row-S 行共享(RS)：共享表锁，sub share
3：Row-X 行独占(RX)：用于行的修改，sub exclusive
4：Share 共享锁(S)：阻止其他DML操作，share
5：S/Row-X 共享行独占(SRX)：阻止其他事务操作，share/sub exclusive
6：exclusive 独占(X)：独立访问使用，exclusive
数字越大锁级别越高, 影响的操作越多。
1级锁有：Select，有时会在v$locked_object出现。
2级锁有：Select for update,Lock For Update,Lock Row Share
select for update当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或select for update操作。
3级锁有：Insert, Update, Delete, Lock Row Exclusive
没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。
4级锁有：Create Index, Lock Share
locked_mode为2,3,4不影响DML(insert,delete,update,select)操作, 但DDL(alter,drop等)操作会提示ora-00054错误。
00054, 00000, "resource busy and acquire with NOWAIT specified"
// *Cause: Resource interested is busy.
// *Action: Retry if necessary.
5级锁有：Lock Share Row Exclusive
具体来讲有主外键约束时update / delete ... ; 可能会产生4,5的锁。
6级锁有：Alter table, Drop table, Drop Index, Truncate table, Lock Exclusive
附上几条简单的oracle系统查询语句：
--查某session 正在执行的sql语句，从而可以快速定位到哪些操作或者代码导致事务一直进行没有结束等.
SELECT
sql_text
FROM v$sqltext a
WHERE (a.hash_value, a.address) IN
(SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),
DECODE(sql_hash_value, 0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.sid = '233')
ORDER BY piece ASC;
--查进程.
select * from v$process ;
--查缩
select * from v$lock;
--查缩定的对象
select * from v$locked_object
--查事务
select * from v$transaction
--查session
select v.* from v$session v where machine='xxx' and username='xxx' and status='INACTIVE' order by last_call_et desc
--查dba_objects对象
select * from dba_objects
where object_id = '14977'
--查缩定的表
select t2.username,t2.sid,t2.serial#,t3.object_name,t2.OSUSER,t2.MACHINE,t2.PROGRAM,t2.COMMAND,t2.LAST_CALL_ET
from v$locked_object t1,v$session t2 ,dba_objects t3
where t1.session_id=t2.sid and t1.object_id = t3.object_id
order by t2.logon_time;
