关于自治事务和锁 PRAGMA AUTONOMOUS_TRANSACTION & LOCK

之前遇到的一个问题, 可以稳定重现.

Oracle 的 INV 提供了一个接口 inv_lot_api_pub.auto_gen_lot() , 用来自动为 item 产生 lot number, 调用一次这个接口, lot number 就会自动 + 1; 看里头的代码, 是先从 MTL_SYSTEM_ITEMS 这个表里面取出一个字段 start_auto_lot_number, 比方说取出来的数值是1000, 那么就会把 1000 当做当前的 lot number, 接着会调用一个 procedure, 去更新这个字段, 变成 1001. 这个procedure 名字叫做 update_msi(). 最后去验证 1000 这个 lot number 是不是已经存在了. 如果存在, 那么会重新取出 1001 当做当前 lot number, 并且验证是不是存在, 直到找到没有重复的lot number, 就把它返回给调用 api 的地方.

那么这段代码会有什么问题呢? 我们假设一个场景, 有两个 session 同时调用这个 api, 那么在从 MSI 取数据的阶段, 有可能两个 session 会取出来相同的lot number. 嗯, 这个是有可能的. 如果这两个 session 是在为同一个 item 产生 lot number 就还好, 但是如果是不同的item, 就会为不同的两个 item 产生相同的 lot number. 这样数据就错了.

解决的办法就是通过锁来锁住被选择的 lot number, 并且在更新成功之后释放锁.

锁住选择的数据的方法是使用 for update 语句

     SELECT auto_lot_alpha_prefix,
            start_auto_lot_number
       INTO l_lot_prefix,
            l_lot_suffix
       FROM mtl_system_items
      WHERE organization_id = p_org_id
        AND inventory_item_id = p_inventory_item_id for update

一旦有数据被选中, 那么同样使用这个 SQL 的session 将不能获得这些数据, 这就保证了无法产生相同的lot number. 当成功更新 lot number 之后, 就可以用 commit 释放锁了.

那么问题来了, 如果我们使用 commit 提交这个事务, 将会把所有的事务处理都提交, 那么如果之后出现错误回滚了, 将会有一部分数据提交, 另一部分数据回滚了. 解决的办法是使用自治事务. 从 select for update 语句开始, 到update MSI 并 commit 为止, 我们定义一个 procedure 并声明这是一个 PRAGMA AUTONOMOUS_TRANSACTION. 这样提交事务的时候就只会提交这个自治事务所做的更改, 并且释放锁给其他语句使用. 在自治事务之外的数据更新操作都不会受到影响.

这样通过锁和声明自治事务, 就可以保证不会在两个 session 里面获取到相同的 lot number 了;

2015年3月18日 补充-------------------

用下面的查询可以找到锁住某个表的进程, 如果不需要可以kill 掉

SELECT A.OBJECT_NAME, b.ORACLE_USERNAME, b.OS_USER_NAME, c.SID, c.SERIAL#
FROM ALL_OBJECTS A,V$LOCKED_OBJECT B,SYS.GV_$SESSION C
WHERE (A.OBJECT_ID = B.OBJECT_ID) AND (B.PROCESS = C.PROCESS)
and OBJECT_NAME = '&TABLE_NAME';

alter system kill session 'sid, serial#';