本文详解如何在 jsr-352 批处理作业中通过 batchlet 正确执行 jpa 删除语句，重点解决 `transactionrequiredexception` 异常，并推荐使用 jdbc + 手动事务管理作为可靠替代方案。
在基于 JSR-352 的 Java EE/Jakarta EE 批处理（如 Payara、WildFly、Open Liberty）中，直接在 Batchlet 中调用 JPA EntityManager#createQuery(...).executeUpdate() 执行 DELETE 或 UPDATE 操作时，常会遇到如下异常：
javax.persistence.TransactionRequiredException: Executing an update/delete query
根本原因在于：
JSR-352 规范明确要求——Batchlet#doProcess() 方法默认运行在 容器管理的无事务上下文（no transaction context） 中。即使你注入了 @PersistenceContext，该 EntityManager 也处于 transactionless 状态，无法自动参与或启动 JTA 事务。更关键的是，批处理容器会在进入 Batchlet 时主动挂起当前事务（如果存在），以确保 Batchlet 的执行具有独立性与可控性。因此，无论是否手动调用 begin()/commit()，JPA 都无法获取有效事务边界。
✅ 推荐方案：使用 JDBC + 显式事务管理
绕过 JPA 的事务依赖，改用原生 JDBC 是最简洁、可靠且符合规范的做法。它完全规避了容器对 EntityManager 事务上下文的限制，同时保持对数据一致性的精确控制。
示例代码（带事务保障）
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.annotation.Resource(lookup = "java:jboss/datasources/ExampleDS") // 根据实际环境调整 JNDI 名
private DataSource dataSource;
@Inject
@BatchProperty(name = "technologyIds")
private String technologyIds;
@Override
public String doProcess() throws Exception {
if (technologyIds == null || technologyIds.trim().isEmpty()) {
throw new IllegalStateException("technologyIds property must be provided");
}
String[] ids = Arrays.stream(technologyIds.split(","))
.map(String::trim)
.filter(s -> !s.isEmpty())
.toArray(String[]::new);
try (Connection conn = dataSource.getConnection()) {
conn.setAutoCommit(false); // 关键：禁用自动提交，启用手动事务
String sql = "DELETE FROM record WHERE technology_id = ?";
try (PreparedStatement ps = conn.prepareStatement(sql)) {
for (String idStr : ids) {
long techId = Long.parseLong(idStr);
ps.setLong(1, techId);
int deleted = ps.executeUpdate();
System.out.println("Deleted " + deleted + " records for technology_id = " + techId);
}
conn.commit(); // 显式提交
return "COMPLETED";
} catch (Exception e) {
conn.rollback(); // 出错回滚
throw e;
}
}
}
}✅ 优势说明： 完全脱离 JPA 事务生命周期约束； 支持批量参数化执行（避免 SQL 注入）； 可精准控制 commit/rollback，保障数据一致性； 兼容所有支持 JTA 或非 JTA 的数据源（包括 @DataSourceDefinition 定义的嵌入式源）。
⚠️ 注意事项与最佳实践
- 不要尝试“修复”JPA 方案：试图通过 @Transactional、UserTransaction 或 EntityManagerFactory.createEntityManager() 手动创建 EM 均不可靠——JSR-352 容器不保证其事务传播行为，且易引发资源泄漏或 IllegalStateException。
- JNDI 数据源是首选：务必通过 @Resource(lookup="...") 注入容器托管的 DataSource，而非硬编码连接字符串；这确保连接池、事务同步及安全管理均由应用服务器统一管控。
- 严格关闭资源：使用 try-with-resources 确保 Connection 和 PreparedStatement 在任何路径下均被释放。
- 日志与监控：建议记录实际删除行数（executeUpdate() 返回值），便于后续审计与故障排查。
- 幂等性设计：若作业可能重试，DELETE 条件应足够精确（如含时间戳或状态过滤），避免重复执行导致误删。
总结
在 JSR-352 批处理中执行 DML 操作（尤其是 DELETE），不应强求复用 JPA 的声明式事务模型。采用 JDBC + 显式事务控制是最符合规范、最稳定可控的实践路径。 它不仅解决了 TransactionRequiredException 的技术障碍，还提升了作业的可预测性与运维可观测性。将此模式封装为通用工具类（如 JdbcBatchExecutor），更能提升团队批处理开发效率与质量水位。
