本文详解在 jsr-352 批处理作业中通过 batchlet 执行 jpa 删除语句失败的根本原因，并提供基于 jdbc 的可靠替代方案，包括事务控制、资源管理及生产级注意事项。
在 Java EE/Jakarta EE 环境下使用 JSR-352（Java Batch）开发数据清理类任务时，开发者常误以为可直接复用容器托管的 EntityManager 执行 DELETE 或 UPDATE JPQL 语句。然而，如示例代码所示，即使注入了 @PersistenceContext，调用 executeUpdate() 仍会抛出 javax.persistence.TransactionRequiredException ——这不是配置错误，而是 JSR-352 规范与 JTA 事务生命周期协同机制的必然结果。
根本原因：Batchlet 运行时事务被挂起
JSR-352 规范明确规定：Batchlet 的 doProcess() 方法不在容器事务上下文中执行。当批处理引擎启动一个 Batchlet 步骤时，它会主动挂起当前可能存在的 JTA 事务（例如由前序 Chunk 步骤开启的事务），以确保该步骤具有独立的生命周期和故障隔离能力。因此：
- 容器注入的 EntityManager 虽然可用，但其底层 JtaTransactionManager 无法关联活跃事务；
- entityManager.getTransaction().begin() 等手动事务操作在 JTA 环境中被禁止（将抛出 IllegalStateException）；
- 即使切换为 RESOURCE_LOCAL 持久化单元，Persistence.createEntityManagerFactory(...) 创建的 EM 也缺乏事务协调器支持，无法自动参与或启动事务。
简言之：Batchlet ≠ 事务边界；JPA 更新操作 ≠ 无事务环境友好型操作。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
推荐方案：使用原生 JDBC + 显式事务管理
绕过 JPA 层，直接使用 DataSource 获取连接并控制事务，是 JSR-352 中执行 DML 操作最稳定、最符合规范的方式。以下是经过验证的生产就绪实现：
立即学习“Java免费学习笔记（深入）”；
package com.example.batch;
import javax.batch.api.BatchProperty;
import javax.inject.Inject;
import javax.inject.Named;
import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.util.Arrays;
@Named("CleanerBatchlet")
public class CleanerBatchlet extends AbstractBatchlet {
@Inject
@javax.batch.annotation.BatchProperty(name = "technologyIds")
private String technologyIds;
@Inject
private DataSource dataSource; // 容器托管的数据源（JTA or non-JTA）
@Override
public String doProcess() throws Exception {
if (technologyIds == null || technologyIds.trim().isEmpty()) {
throw new IllegalArgumentException("technologyIds property must be specified");
}
long[] ids = Arrays.stream(technologyIds.split(","))
.map(String::trim)
.mapToLong(Long::parseLong)
.toArray();
for (long techId : ids) {
deleteRecordsByTechnologyId(techId);
}
return "COMPLETED";
}
private void deleteRecordsByTechnologyId(long technologyId) throws Exception {
String sql = "DELETE FROM record WHERE technology_id = ?";
try (Connection conn = dataSource.getConnection()) {
// 启用事务（JTA 环境下由容器管理；非 JTA 下需手动 commit/rollback）
conn.setAutoCommit(false); // 关键：禁用自动提交
try (PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setLong(1, technologyId);
int deleted = ps.executeUpdate();
conn.commit(); // 显式提交
System.out.println("Deleted " + deleted + " records for technologyId=" + technologyId);
} catch (Exception e) {
conn.rollback(); // 出错回滚
throw e;
}
}
}
}✅ 关键要点说明：使用 @Inject DataSource 而非 @PersistenceContext，确保获取到的是容器管理的连接池实例；conn.setAutoCommit(false) 是启用事务控制的前提（即使在 JTA 环境中，此设置亦被忽略，但无害且增强可移植性）；try-with-resources 自动关闭 Connection 和 PreparedStatement，避免连接泄漏；显式 commit() / rollback() 提供确定性行为，不依赖容器事务传播。
注意事项与最佳实践
- 不要尝试“修复”JPA 方案：试图通过 @Transactional 注解、自定义 UserTransaction 或 EntityManagerFactory 手动创建 EM 均违反 JSR-352 设计原则，且在多数应用服务器（WildFly、Payara、Open Liberty）中不可靠。
- SQL 注入防护：示例中使用 PreparedStatement 绑定参数，严禁拼接 SQL 字符串（尤其当 technologyIds 来自外部输入时）。
- 批量删除优化：若需删除大量记录，考虑改用 IN 子句或分页执行（如 WHERE id BETWEEN ? AND ?），避免单条语句锁表过久。
- 日志与监控：建议记录实际影响行数（executeUpdate() 返回值）及执行耗时，便于运维追踪与性能分析。
- 幂等性设计：将 CleanerBatchlet 设计为幂等（例如先 SELECT COUNT(*) 再删），确保重试不会引发异常状态。
综上，面对 JSR-352 中的 DML 需求，拥抱 JDBC 并合理管理连接与事务，不仅是技术上的最优解，更是对批处理架构约束的尊重。清晰区分「数据读取/转换」（适合 Chunk 模式 + JPA）与「原子性数据清理」（适合 Batchlet + JDBC），方能构建健壮、可维护的企业级批处理系统。
