在无状态EJB中使用JPA时，一旦persist()触发重复键异常（如ConstraintViolationException），整个事务将自动回滚，导致此前所有未提交的persist()操作（包括客户和产品实体）均不会写入数据库。
在无状态ejb中使用jpa时，一旦`persist()`触发重复键异常（如`constraintviolationexception`），整个事务将自动回滚，导致此前所有未提交的`persist()`操作（包括客户和产品实体）均不会写入数据库。
JPA规范明确规定：EntityManager.persist() 是一个事务性操作，其语义并非“立即执行INSERT”，而是将实体标记为“托管（managed）并待插入”。真正的SQL INSERT通常延迟到 flush() 或事务提交时才执行。因此，在您的代码中：
-
em.persist(customerEntity)和em.persist(prod1)并未立即落库，仅将实体注册进一级缓存； -
em.flush()强制同步，此时customerEntity被插入（假设主键合法）； - 后续
em.persist(prod2)注册后，当事务最终提交（或隐式 flush）时，JPA 尝试插入prod2，但因违反唯一约束抛出ConstraintViolationException；
关键点在于：该异常属于 JTA 事务的严重错误，容器会自动标记事务为 rollback-only。即使您用 try-catch 捕获了异常，事务上下文已不可恢复——customerEntity 和 prod1 的变更仍会被回滚，数据库保持原子一致性。
✅ 正确做法不是“捕获后继续”，而是避免异常发生或隔离风险操作。
推荐解决方案
1. 使用 merge() 替代 persist()（适用于主键可预知场景）
// 若 product 实体主键由业务生成（如 code 字段），可用 merge 实现“存在则忽略，不存在则插入” Product prod2 = ...; Product merged = em.merge(prod2); // 若已存在，返回托管实例；若不存在，等效 persist + flush
⚠️ 注意：merge() 不保证 INSERT，它可能执行 SELECT + UPDATE，且不适用于自增主键未赋值的场景。
2. 显式检查 + 条件插入（推荐用于严格控制逻辑）
if (!em.createQuery("SELECT 1 FROM Product p WHERE p.code = :code", Integer.class)
.setParameter("code", prod2.getCode())
.getResultList().isEmpty()) {
em.persist(prod2);
} else {
// 可选：记录警告或跳过
System.out.println("Product " + prod2.getCode() + " already exists.");
}3. 使用数据库原生 UPSERT（需 Provider 支持）
例如 EclipseLink 支持 @InsertObject + 自定义 SQL；Hibernate 6+ 提供 Session.upsert()；或通过 @Modifying @Query 执行 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 INSERT IGNORE（MySQL）。
重要注意事项
- ❌ 不要依赖
try-catch吞掉持久化异常来“挽救”部分数据——JPA 事务不具备部分提交能力； - ✅ 无状态Bean默认使用容器管理的 JTA 事务，
@TransactionAttribute(REQUIRED)下整个方法运行于单事务中； - ? 若必须分步提交，可拆分为多个带
@TransactionAttribute(REQUIRES_NEW)的私有方法，但需权衡分布式事务复杂度； - ? 开发阶段建议开启
hibernate.show_sql=true和org.hibernate.type.descriptor.sql.BasicBinder=TRACE，观察实际 SQL 时序。
综上，JPA 的设计哲学是“失败即终止”，而非“尽力而为”。理解事务边界与 persist() 的延迟语义，是编写健壮数据访问层的基础。
