OracleTransaction.Commit()未生效的根本原因是连接被意外关闭或复用，导致Dispose()时强制回滚；务必确保Commit()在Connection仍打开且未释放前执行。
OracleTransaction.Commit() 为什么没生效？
常见现象是调用 commit() 后查数据库发现数据没变，或事务中途被自动提交。根本原因通常是连接被意外复用或提前关闭——oracleconnection 在 dispose() 或离开 using 块时，会强制回滚未完成的事务，哪怕你已经调用了 commit()。
实操建议：
- 确保
OracleTransaction和它所属的OracleConnection生命周期严格对齐：事务必须在连接仍打开且未释放前完成Commit()或Rollback() - 不要把
OracleConnection存在静态字段或长生命周期对象里；每次事务都应新建或从连接池安全获取 - 避免在
try块里只捕获特定异常而漏掉OracleException或连接中断类错误，导致事务状态悬空 - 示例中易错写法：
using (var conn = new OracleConnection(connStr)) { conn.Open(); using (var tx = conn.BeginTransaction()) { // ... 执行命令 tx.Commit(); // ✅ 正确 } // ❌ 这里 conn 还活着，tx 已 Dispose，但没问题 }但如果把conn提前Close()或Dispose()，Commit()就会抛InvalidOperationException
BeginTransaction(isolationLevel) 隔离级别不生效？
Oracle 对 SQL 标准隔离级别的支持有限：ReadCommitted 是默认且唯一完全支持的；Serializable 被映射为 Oracle 的 SELECT FOR UPDATE 行为，并非真正的可序列化；RepeatableRead 和 ReadUncommitted 会被静默降级为 ReadCommitted，不报错也不警告。
实操建议：
- 别依赖
RepeatableRead实现两次读一致——Oracle 底层靠多版本并发控制（MVCC），同一事务内普通SELECT天然可重复读，无需额外配置 - 真需要串行化语义，用
SELECT ... FOR UPDATE显式加锁，而不是靠事务级别 - 检查实际生效级别：执行后查
V$TRANSACTION视图的ISOLATION_LEVEL字段，或捕获OracleCommand执行时的警告信息 - 代码中显式指定更安全：
var tx = conn.BeginTransaction(IsolationLevel.ReadCommitted);
比无参调用更明确，也方便后续审计
嵌套事务和 Savepoint 怎么用才可靠？
.NET 的 OracleTransaction 不支持真正嵌套事务（即 BeginTransaction() 套 BeginTransaction()），所谓“嵌套”只是创建保存点（Savepoint）。一旦外层事务回滚，所有保存点失效；但回滚到某个保存点，不会影响外层事务状态。
实操建议：
- 用
tx.Save("sp1")创建保存点，用tx.Rollback("sp1")回滚到它——注意名称区分大小写，且不能重名 - 保存点不是独立事务，不能提交，只能回滚；也不能跨连接或跨命令生命周期存在
- 高频陷阱：在循环中反复创建同名保存点，导致后一次覆盖前一次，
Rollback("sp1")只能回到最后一次设置的位置 - 适合场景：单个业务操作中局部失败需部分撤回（如批量插入时某条违反约束），而非替代分布式事务
OracleException 中哪些错误必须触发 Rollback？
不是所有异常都要回滚。Oracle 报错分三类：连接类（如 ORA-12154）、语法类（ORA-00900）、事务类（ORA-02091、ORA-08176）。只有影响事务一致性的错误才需主动 Rollback()；否则可能掩盖真实问题。
实操建议：
- 重点监控
OracleException.Number：遇到1（SQL 错误）、2091（事务已回滚）、8176（一致性读失败）等，应立即tx.Rollback() - ORA-00001（唯一约束）这类业务错误，可选择性处理：记录日志 +
Rollback()，或捕获后转为用户提示而不回滚整个事务（视业务容忍度） - 网络中断（ORA-03113/03114）发生时，连接通常已断，再调
Rollback()会抛新异常，此时应直接放弃事务并重建连接 - 统一在
catch (OracleException ex)块末尾加if (tx != null && tx.Connection?.State == ConnectionState.Open) tx.Rollback();，比每个分支单独判断更稳妥
Oracle 事务的边界比表面看起来更“粘稠”：连接状态、保存点命名、异常分类，任何一个环节松动都会让回滚变成幻觉。最常被忽略的是连接存活时间——它不只影响性能，直接决定事务是否真的落地。
