本文详解如何在 jdbc 批量操作中正确启用事务控制，通过禁用自动提交、显式调用 commit/rollback 实现 acid 一致性，并规避因 sqlexception 导致部分提交的风险。
在使用 JDBC 进行批量数据操作（如 executeBatch()）时，若未妥善管理事务，极易破坏数据一致性——例如：某一批次插入失败，但此前已成功执行的批次已被自动提交，导致“半成功”状态，严重违背 ACID 原则。核心问题在于：默认的 auto-commit = true 模式下，executeBatch() 的错误行为是驱动依赖且不可靠的，JDBC 规范明确指出（§14.1.1）：当 auto-commit 启用时，发生异常后是否回滚、回滚范围及是否继续执行，均由具体 JDBC 驱动实现决定，不应被信任或依赖。
✅ 正确做法是：始终在批量操作前显式关闭自动提交：
connection.setAutoCommit(false);
此后，所有 DML 操作（包括 executeUpdate() 和 executeBatch()）均纳入同一事务上下文，直至显式调用 connection.commit() 或 connection.rollback()。
✅ 推荐实现结构（含完整异常回滚）
以下为生产就绪的批量插入模板，兼顾可读性、事务完整性与日志可观测性：
public void insertingRowsByBatches(RequestData requestData) {
try (Connection connection = myDataSource.getConnection()) {
connection.setAutoCommit(false); // 关键：禁用自动提交
try (PreparedStatement deleteStmt = connection.prepareStatement("DELETE FROM my_table");
PreparedStatement insertStmt = connection.prepareStatement("INSERT INTO my_table(SOME_DATA) VALUES (?)")) {
// 1. 清空 staging 表（作为事务一部分）
int deleted = deleteStmt.executeUpdate();
log.info("[{}] existing records deleted from staging table", deleted);
// 2. 分批插入（每批独立 prepare，复用同一 Statement）
List data = Optional.ofNullable(requestData.getData()).orElse(List.of());
List> partitions = Lists.partition(data, MAX_ROWS_PER_INSERT);
long totalStart = System.currentTimeMillis();
for (int i = 0; i < partitions.size(); i++) {
List batch = partitions.get(i);
log.debug("Processing batch [{}/{}], size: {}", i + 1, partitions.size(), batch.size());
insertStmt.clearBatch(); // 确保批次干净
for (String recordId : batch) {
insertStmt.setString(1, recordId);
insertStmt.addBatch();
}
int[] results = insertStmt.executeBatch();
log.debug("Batch [{}/{}] executed: {} updates", i + 1, partitions.size(), results.length);
}
// 3. 全局提交 —— 仅当全部批次成功才生效
connection.commit();
long totalTime = System.currentTimeMillis() - totalStart;
log.info("Successfully inserted [{}] rows in {}ms", data.size(), totalTime);
} catch (SQLException e) {
connection.rollback(); // ⚠️ 关键：异常时立即回滚整个事务
log.error("Transaction rolled back due to SQL error: {}", e.getMessage(), e);
throw new GenericRuntimeException("Bulk insert failed and was rolled back", e);
}
} catch (SQLException e) {
throw new GenericRuntimeException("Failed to acquire database connection", e);
}
} ? 关键要点说明
- setAutoCommit(false) 必须在获取 Connection 后、任何 DML 操作前调用，且需确保其作用于整个逻辑事务范围；
- rollback() 应在 catch (SQLException) 中紧随异常捕获之后立即执行，避免因后续代码异常导致回滚遗漏；
- 避免在 forEach() 中嵌套 try-catch：原代码中对每个 partition 单独 try-catch 并吞掉异常，会导致事务无法整体回滚（如第3批失败，前2批已“事实提交”），应改用传统 for 循环并让异常穿透至外层事务处理块；
- clearBatch() 是良好实践：防止上一批残留指令干扰当前批次；
- 日志建议包含批次序号与大小：便于故障定位与性能分析；
- 连接资源由 try-with-resources 自动关闭：即使 rollback 后，Connection 仍需安全释放。
❗ 注意事项
- 若业务要求“单批次失败不影响其他批次”，则需将事务粒度降至每批次一级（即每个 partition 内 setAutoCommit(false) → 操作 → commit()/rollback()），但此时已不满足“全部成功或全部失败”的强一致性语义；
- connection.rollback() 仅对当前事务有效；若连接已关闭或处于已提交状态，调用会抛出 SQLException，因此务必确保其只在活跃事务中执行；
- 生产环境建议配合数据库连接池（如 HikariCP）的事务隔离级别配置（如 TRANSACTION_READ_COMMITTED），并在必要时显式设置 connection.setTransactionIsolation(...)。
遵循以上模式，即可在 JDBC 批量场景中真正实现原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）与持久性（Durability），让数据变更经得起故障考验。
