DBMS_ALERT不是进程/过程间通信工具，因为它仅支持会话级、事务提交触发的轻量信号通知，不传递实际数据；发送需显式COMMIT，接收需提前注册并阻塞等待，仅适用于长生命周期会话间的异步事件感知。
dbms_alert 不能用于“存储过程之间通信”，它只支持会话间、事务提交触发的信号通知；想靠它让两个存储过程直接传递数据或控制流，本质走不通。
为什么 DBMS_ALERT 不是进程/过程间通信工具
它不传数据，只发一个“某事已提交”的轻量信号。DBMS_ALERT.SIGNAL 后必须 COMMIT，接收方才能感知——这意味着发送方存储过程得在可提交上下文中运行（不能是自治事务），而接收方必须长期持有连接并轮询等待。两个存储过程若各自独立执行、无长连接、无显式等待逻辑，信号就彻底丢失。
- 常见误用：A 过程调
DBMS_ALERT.SIGNAL+COMMIT，B 过程紧接着调DBMS_ALERT.WAITONE→ B 会立即超时，因为 WAITONE 是阻塞调用，且要求会话已提前注册 - 真正能跑通的场景，是两个**长生命周期会话**（比如常驻后台的 PL/SQL 块或 Java 应用线程），一方发信号，另一方持续监听
- 它和
DBMS_PIPE有本质区别：DBMS_PIPE可在单次调用中传递字符串/数字等值，DBMS_ALERT的message参数只是附带文本，不可靠、不保证送达、不支持结构化数据
DBMS_ALERT 必须提前注册，且注册绑定到当前会话
接收端必须在调用 WAITONE 或 WAITANY 前，用同一会话执行 DBMS_ALERT.REGISTER。这个动作不是“全局订阅”，而是为当前会话打开一个监听通道。
- 注册名区分大小写，
'UserUpdate'和'userupdate'是两个不同 alert - 重复注册无害，但
DBMS_ALERT.REMOVEALL会清空当前会话所有注册，别在共享连接池里乱用 - 如果接收方是应用层（如 Java），必须确保数据库连接不被连接池回收——否则注册失效，后续
WAITONE直接报ORA-04021: timeout occurred while waiting to lock object或静默失败
SIGNAL 后不 COMMIT = 白发
DBMS_ALERT.SIGNAL 本身只是把信号写入内存队列，不触发广播。只有配套的 COMMIT 才真正将信号推送给所有已注册该名称的会话。
- 典型错误：在存储过程中 SIGNAL，然后 ROLLBACK 或异常退出 → 接收方永远收不到
- 若 SIGNAL 在自治事务中调用，即使 COMMIT 了，信号也不会被其他会话看到（自治事务隔离）
-
WAITONE和WAITANY会隐式 COMMIT 当前事务，所以接收方不用自己 commit；但发送方必须显式 commit，且不能在无法 commit 的上下文里调用（比如只读事务、物化视图日志触发器）
WAITONE 和 WAITANY 的 timeout 别设成默认值
两个等待过程的 timeout 参数默认是 MAXWAIT（约 1000 天），意味着线程会永久挂起。生产环境必须设具体秒数，比如 30 或 60。
-
WAITONE('config_changed', msg, status, 30)：等 30 秒，status = 0表示收到，status = 1表示超时 -
WAITANY(name_out, msg, status, 30)：从本会话所有已注册 alert 中等任意一个，返回时name_out是实际触发的那个名字 - 超时后应主动重试或退出循环，避免线程堆积；不要依赖“永远等待”，这在容器或云环境中极易导致资源泄漏
真正需要跨存储过程传递状态或数据，优先考虑表轮询、DBMS_PIPE（短消息）、或外部消息中间件。DBMS_ALERT 的价值只在一个地方：让多个长连接会话对“某张配置表已被提交更新”达成瞬时共识——其余场景，它既难用又易错。
