自治事务本身不锁死父事务，但若其操作父事务正修改的同一行，因oracle锁机制冲突（如x锁互斥），自治事务无法获取锁而报错（如ora-00054），若被忽略则导致父事务后续commit阻塞甚至死锁。

自治事务本身不会导致父事务锁死，真正卡住的是“在自治事务里操作了父事务正在修改的同一行”

为什么自治事务执行完，父事务还卡在UPDATE上？

常见现象是：父事务 UPDATE 了一行，自治事务里又对同一行做了 INSERT/UPDATE/DELETE，之后父事务 commit 时 hang 住，甚至超时抛出 ORA-00060（死锁）或 ORA-04021（timeout acquiring lock）。这不是自治事务“锁死了父事务”，而是 Oracle 的事务隔离机制在起作用：

• 自治事务和父事务完全独立，各自有独立的 SCN 和回滚段，但它们共享同一个会话（session）和底层数据块缓存
• 父事务已加 X 锁（排它锁）的行，自治事务无法再对其加 X 锁——除非父事务先释放（即 commit 或 rollback）
• 而自治事务又不能“等父事务提交”，它必须自己完成、提交或回滚；于是它会尝试获取锁，失败后立即报错（如 ORA-00054: resource busy），但很多人忽略了这个错误，继续往下走，导致父事务后续操作被阻塞

PRAGMA AUTONOMOUS_TRANSACTION 后第一个 BEGIN 就脱离父事务上下文

自治事务的边界非常明确：从 PRAGMA AUTONOMOUS_TRANSACTION 所在 PL/SQL 块中，**第一个 BEGIN 开始**，到对应 END 结束，整个块就是自治事务。注意几个关键点：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• DECLARE 部分声明的变量、游标、异常定义，仍属于父事务作用域；只有 EXECUTE 部分才进入自治事务
• 自治事务里调用的任何存储过程、函数、触发器，只要没显式再写 PRAGMA AUTONOMOUS_TRANSACTION，就自动归属当前自治事务，不是父事务
• 自治事务可以提交（COMMIT）或回滚（ROLLBACK），但这些操作对父事务不可见——父事务看不到自治事务写的未提交数据，反之亦然（READ COMMITTED 下）

哪些写法最容易引发锁冲突？

典型高危组合：

• 父事务 UPDATE 表 A 的某条记录 → 自治事务 INSERT/UPDATE/DELETE 同一条记录（主键或唯一键相同）
• 父事务执行 SELECT ... FOR UPDATE 锁住某行 → 自治事务对该行做 DML
• 触发器里用自治事务写日志表，但日志表上有触发器、外键约束或物化视图日志，间接导致锁链延伸到父事务涉及的表
• 自治事务里调用了含隐式 COMMIT 的 DBMS_* 包（如 DBMS_MVIEW.REFRESH），虽不常见，但一旦发生，会强制结束当前自治事务，可能留下不一致状态

如何验证是不是自治事务引发的锁等待？

别只查 V$LOCKED_OBJECT，它不显示自治事务的锁持有者。要抓实时会话状态：

• 查锁等待链：SELECT blocking_session, sid, serial#, event, sql_id FROM v$session WHERE blocking_session IS NOT NULL
• 确认自治事务是否还在运行：SELECT s.sid, s.serial#, s.status, t.start_time, t.used_ublk FROM v$transaction t JOIN v$session s ON s.taddr = t.addr —— 如果看到多个 sid 对应不同 start_time 且都未提交，大概率存在嵌套自治事务
• 在自治事务内部加日志（如写入 DBMS_APPLICATION_INFO.SET_MODULE），便于在 V$SESSION 中区分父/自治会话上下文

最常被忽略的一点：自治事务的“独立性”是逻辑上的，不是物理隔离的。它不绕过锁机制，也不跳过一致性读规则。想让它不干扰父事务，唯一可靠方式是——让它操作完全无关的数据集。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南