本文详解如何在 jdbc 批量插入场景中正确启用事务控制、捕获 sqlexception 并执行原子性回滚，确保数据符合 acid 原则，避免部分提交导致的数据不一致问题。
在使用 JDBC 进行批量数据操作（如 executeBatch()）时，默认的自动提交（auto-commit）模式会严重破坏事务一致性。根据 JDBC 规范（JSR 367, Section 14.1.1），当 autoCommit = true 时，executeBatch() 的错误行为是驱动程序实现相关的——某些驱动可能在批处理中途失败后仍提交已成功执行的语句，这直接违反 ACID 中的 Atomicity（原子性） 和 Consistency（一致性）。
✅ 正确做法是：显式关闭自动提交，并统一由应用控制 commit/rollback 的时机：
private void loadInStagingTable(RequestData requestData, Connection connection) throws SQLException {
connection.setAutoCommit(false); // 关键：禁用 auto-commit
try (PreparedStatement deleteStmt = connection.prepareStatement("DELETE FROM my_table");
PreparedStatement insertStmt = connection.prepareStatement("INSERT INTO my_table(SOME_DATA) VALUES (?)", Statement.RETURN_GENERATED_KEYS)) {
// 清空目标表（作为单个逻辑单元）
deleteStmt.executeUpdate();
log.info("Cleared existing records from staging table");
// 分批插入（所有批次属于同一事务）
List allRecords = Optional.ofNullable(requestData.getData()).orElse(Collections.emptyList());
List> partitions = Lists.partition(allRecords, MAX_ROWS_PER_INSERT);
long startTime = System.currentTimeMillis();
for (int i = 0; i < partitions.size(); i++) {
List batch = partitions.get(i);
log.debug("Processing batch {}/{} ({} rows)", i + 1, partitions.size(), batch.size());
insertStmt.clearBatch();
for (String recordId : batch) {
insertStmt.setString(1, recordId);
insertStmt.addBatch();
}
int[] results = insertStmt.executeBatch();
// 可选：校验 batch 结果（如检查是否有 EXECUTE_FAILED）
if (Arrays.stream(results).anyMatch(r -> r == Statement.EXECUTE_FAILED)) {
throw new SQLException("Batch execution failed with EXECUTE_FAILED status");
}
}
connection.commit(); // 全部成功才提交
long duration = System.currentTimeMillis() - startTime;
log.info("Successfully inserted {} rows in {}ms", allRecords.size(), duration);
} catch (SQLException e) {
connection.rollback(); // 关键：出错立即回滚整个事务
log.error("Transaction rolled back due to SQL error: {}", e.getMessage(), e);
throw e; // 或包装为业务异常（如 GenericRuntimeException）
}
} ? 关键要点说明：
- setAutoCommit(false) 必须在获取 Connection 后、任何 DML 操作前调用，且不可遗漏；
- rollback() 应在 catch 块中紧随异常捕获之后执行，确保连接状态可恢复；
- 避免在 try-with-resources 中嵌套多个 PreparedStatement 时意外提前关闭连接（如原代码中 connection 被外层 try 管理，内层 PreparedStatement 不影响其生命周期）；
- 不要使用 forEach + lambda 处理批处理逻辑：它无法中断迭代或向上抛出受检异常，易掩盖错误传播路径；推荐传统 for 循环以保证控制流清晰；
- executeBatch() 返回 int[] 数组，建议校验结果（如是否存在 Statement.EXECUTE_FAILED），增强健壮性；
- 若需更细粒度控制（例如按分区独立回滚），应设计为多个独立事务（每个 partition 单独 commit/rollback），但此时已不属于“全量 ACID”语义，需明确业务权衡。
? 额外建议：
- 使用 DataSource 获取连接时，确认连接池（如 HikariCP）未强制重置 autoCommit（可通过 HikariConfig.setConnectionInitSql("SET autocommit = 0") 防御）；
- 在日志中记录事务 ID 或请求 traceId，便于故障排查与审计；
- 对于超大批量场景，考虑结合 savepoint 实现分段回滚（高级用法，本文未展开）。
遵循以上实践，即可确保 JDBC 批量操作真正满足 ACID 要求：任一环节失败，所有变更均被彻底撤销，数据库始终处于一致状态。
