Spring Batch特定环境报错：Transaction silently rolled back because it has been marked as rollback-only

1. 数据库环境差异定位 #

• 检查表结构实际匹配度：虽然已核对DDL，但需直接查询特定环境的table1表结构（执行desc table1），对比代码中插入SQL的列数、字段类型、约束：
  • 注意到你提供的插入SQL存在列数与值数量不匹配的问题：SQL中列定义为8个（created_by到id），但值列表有9个参数（最后多了1, ?），需确认这是否是笔误，或是特定环境表结构多了一个字段（比如额外的状态字段）导致SQL与表结构不兼容。
• 验证数据库约束与权限：
  • 检查table1的非空约束、唯一键约束、主键序列（若id依赖序列生成），确认特定环境的输入数据是否违反这些约束（比如cc_key重复、created_by为空）。
  • 确认应用使用的数据库用户是否拥有table1的插入权限，以及序列的访问权限（若涉及）。
• 检查数据库参数限制：
  • 查看Oracle的open_cursors、processes参数值，是否因批量插入导致游标耗尽；检查undo_retention参数，是否存在事务回滚时的空间不足问题。
  • 对比不同环境的事务隔离级别，特定环境若使用更严格的隔离级别（比如SERIALIZABLE），可能导致锁超时或批量操作失败。

2. Spring Batch事务与批量配置排查 #

• 跟踪事务回滚触发点：
  • 开启org.springframework.transaction和org.springframework.batch的DEBUG日志，查看事务创建、标记为rollback-only的具体流程，确认是批量插入异常直接导致事务标记回滚，还是其他内层事务操作触发。
  • 注意：Spring Batch的Step事务默认传播行为为REQUIRED，若ItemWriter中的批量操作抛出未捕获异常，会将当前事务标记为rollback-only，Step提交时就会触发UnexpectedRollbackException。
• 核对批量处理配置：
  • 检查特定环境的chunk size配置，若该值远大于其他环境，可能导致单次批量插入数据量过大，触发数据库的日志大小或锁限制。
  • 确认ItemWriter的批量操作逻辑：若使用JdbcTemplate.batchUpdate，需确保异常被正确捕获并打印具体错误（比如BatchUpdateException.getNextException()可获取Oracle原生错误码）。

3. 数据差异验证 #

• 模拟特定环境数据：将特定环境的输入数据（待插入到table1的数据）复制到本地或测试环境，执行相同的批量插入操作，查看是否复现报错。若能复现，即可定位为数据本身存在违反约束的问题。
• 检查特殊数据值：重点排查是否存在超长字符串、特殊字符（比如非UTF-8编码字符）、NULL值（违反非空约束）等，这些数据在其他环境未出现，仅在特定环境存在。

4. 依赖与类加载排查 #

• 核对依赖版本：确认特定环境的Oracle驱动版本（比如ojdbc11 vs ojdbc8）是否与本地/高阶环境一致，不同版本的驱动在批量插入的处理逻辑上可能存在差异。
• 排查jar包冲突：检查特定环境的应用依赖是否存在冲突（比如Spring事务、Spring Batch相关的jar包版本不一致），可通过mvn dependency:tree（Maven）或gradle dependencies（Gradle）对比不同环境的依赖树。

内容的提问来源于stack exchange，提问作者Achyut Muley