原文地址: https://blogs.ontoorsolutions.com/post/using-apex-collections-safely-avoiding-session-state-leaks/ # 安全使用 APEX 集合：避免会话状态泄漏 Oracle APEX 集合是会话作用域的数据容器，设计用于在活跃用户会话期间保存临时数据。它们使用简单、功能强大，并且完全由 APEX 引擎管理。  然而，如果使用集合时没有明确的生命周期规划，它们可能导致会话数据不必要地增长、行为不可预测，并且产生不一致或重复的信息——这些问题通常被错误地称为内存泄漏。 ## 理解 APEX 集合的作用域（Oracle APEX 标准） 根据 Oracle APEX 架构的定义： - APEX 集合是会话作用域的 - 它们仅在 APEX 会话的生命周期内存在 - 会话结束时它们会自动被删除 - 它们在以下情况下持续存在： - 页面导航 - 页面刷新 - 验证失败 Oracle APEX 保证在会话终止时清理集合。这意味着： - 不存在永久性的内存泄漏 - 所有风险都存在于活跃会话中 ## 开发者所谓的“内存泄漏”（正确术语） 在 Oracle APEX 中，真正的问题是： - 活跃会话中会话状态的失控增长 这种情况发生在以下情况： - 集合被反复填充 - 旧数据未被清除 - 集合的使用超出了其业务目的 更准确的术语是： - 会话状态泄漏（当临时的 APEX 数据在会话中保留时间超过所需时，导致不可预测的表单行为、重复数据和调试挑战） ## 现实场景：供应商登记流程 业务需求是一个有四个步骤的供应商登记流程： 1. 供应商标题详情 2. 多个地址 3. 银行和税务信息 4. 审核并最终提交 用户行为包括： - 前进和后退导航 - 验证校正 - 页面刷新 - 可能的取消 ## 常见实现（符合标准但有风险） 典型的做法是： - 每个步骤一个集合 - 数据暂存到集合中 - 提交时最终持久化 最初，流程工作正常。但随着时间的推移： - 出现重复记录 - 旧数据重新出现 - 问题在登出后消失 - QA 无法一致复现 这种行为不是错误，也不是 APEX 的缺陷。这是缺乏生命周期控制的结果。 ## 核心架构规则：定义集合所有权 Oracle APEX 不强制执行所有权规则——这需要架构师来完成。每个集合必须有： - 明确的业务目的 - 定义的所有者（流程或模块） - 保证的销毁事件 ```html <table> <tr><th>集合</th><th>目的</th><th>所有者</th><th>销毁时机</th></tr> <tr><td>VENDOR_HDR</td><td>供应商标题暂存</td><td>登记流程</td><td>提交/取消</td></tr> <tr><td>VENDOR_ADDR</td><td>地址暂存</td><td>登记流程</td><td>提交/取消</td></tr> <tr><td>TEMP_UPLOAD</td><td>文件暂存</td><td>上传页面</td><td>页面退出</td></tr> </table> ``` ## Safe Start 模式 为了防止重复数据和不可预测的行为，集合必须在业务流程开始时明确且安全地初始化。 推荐的安全启动模式： ```sql -- Oracle APEX 的 Safe Start 模式 IF NOT APEX_COLLECTION.COLLECTION_EXISTS( p_collection_name => 'VENDOR_HDR' ) THEN APEX_COLLECTION.CREATE_COLLECTION( p_collection_name => 'VENDOR_HDR' ); ELSE APEX_COLLECTION.TRUNCATE_COLLECTION( p_collection_name => 'VENDOR_HDR' ); END IF; ``` ## 集合与表的比较：架构级决策矩阵 ```html <table> <tr><th>需求</th><th>集合</th><th>表</th></tr> <tr><td>临时 UI 状态</td><td>是</td><td>否</td></tr> <tr><td>同会话向导</td><td>是</td><td>视情况</td></tr> <tr><td>跨会话草稿</td><td>否</td><td>是</td></tr> <tr><td>审计与恢复</td><td>否</td><td>是</td></tr> <tr><td>大容量数据</td><td>否</td><td>是</td></tr> </table> ``` # 结束语 APEX 集合的行为完全符合 Oracle 的设计初衷。开发者遇到的问题很少源于错误的语法或 API 使用，大多是缺乏对会话状态所有权和生命周期管理的架构纪律。