java批量提交oracle数据未回滚的根本原因是事务未显式开启或已提前结束：必须在addbatch前调用setautocommit(false)，捕获batchupdateexception并手动rollback，且需注意连接池复位、驱动隐式降级及@transactional失效场景。
Java 批量提交 Oracle 数据时没触发事务回滚，根本原因不是“回滚失效”，而是事务压根没被正确开启或已提前结束——executeBatch() 执行成功不等于事务生效，更不等于异常能自动传播。
PreparedStatement 批量执行前没关自动提交
Oracle 的事务边界由 setAutoCommit(false) 显式划定，不是靠 addBatch() 自动开启。如果漏掉这步，每条 executeBatch() 都是独立提交，失败时连事务上下文都没有，自然谈不上回滚。
- 必须在获取
Connection后、第一次addBatch()前调用conn.setAutoCommit(false) - 若使用连接池（如 HikariCP），该设置不会自动重置，需在归还连接前手动恢复
setAutoCommit(true)，否则污染后续借用者 - 别依赖“最后 close 连接时自动提交”来掩盖问题——那是 Oracle JDBC 驱动的兜底行为，不是事务设计本意
BatchUpdateException 被吞掉或没处理
Oracle 批量出错（如主键冲突、字段超长）抛的是 BatchUpdateException，但它的 getMessage() 常为空或只写 “could not execute JDBC batch update”，真实 ORA- 错误藏在 getCause() 或 getNextException() 里。
- 不能只 catch
SQLException，必须显式捕获BatchUpdateException - 要遍历
getUpdateCounts()数组：遇到-2表示“执行成功但行数未知”，遇到EXECUTE_FAILED（即 -3）才代表某条失败 - 别用
int[]全为正数作为“全部成功”的判断依据——Oracle 就不返回真实计数
@Transactional 在批量场景下未生效
Spring 的 @Transactional 对批量操作无效，常见于两类误用：
- 同类中用
this.executeBatch()调用，导致代理失效，事务切面根本没挂上 - 方法标了
@Transactional，但实际执行的是PreparedStatement.addBatch()+executeBatch()，而事务管理器无法感知 JDBC 底层批处理的原子性，只认单条 SQL 提交点 - 异步方法（
@Async）里加@Transactional，但没配TransactionManager支持跨线程传播，事务上下文丢失
Oracle 驱动对批处理的隐式限制
即使代码结构看起来没问题，Oracle JDBC 驱动也可能悄悄降级为逐行执行，导致事务控制失灵：
-
SetBigStringTryClob=true且目标字段是VARCHAR2→ 触发隐式类型转换 → 优化器拒绝批处理计划 - SQL 中混用字面量和参数（如
WHERE status = 'ACTIVE' AND id = ?）→ 游标无法共享 → 批处理缓存失效，退化为单条执行 - 未复用同一个
PreparedStatement实例：每次conn.prepareStatement(sql)都新建对象，addBatch()彼此隔离
最常被忽略的一点：Oracle 的事务提交/回滚不是靠“有没有报错”决定的，而是看 commit() 或 rollback() 是否被显式调用——哪怕 executeBatch() 抛了 BatchUpdateException，如果你没在 catch 里调 conn.rollback()，连接关闭时它仍会默认提交。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
