@Transactional注解在删除方法中使用触发非空约束异常求助

出现这个问题的核心原因是：添加@Transactional后，JPA/Hibernate的事务上下文会延迟执行SQL操作（直到事务提交前才批量执行），导致SQL执行顺序和代码逻辑顺序不一致。无事务时，每个DAO操作都会立即提交执行，先删违规记录、再删车辆的顺序是严格的；但加入事务后，JPA可能会调整SQL执行顺序（比如合并所有DELETE操作），如果先执行了删除车辆的SQL，再加上ORM的实体状态同步逻辑，就可能导致违规记录的car_id被意外设置为null，触发非空约束错误。

下面给出几种针对性的解决方案：

方案1：修复removeByCarId的实现（推荐） #

检查violationService.removeByCarId的实现，确保它直接执行批量删除SQL，而非先查询实体再修改：

• 正确实现：在ViolationRepository中定义批量删除方法，让Spring Data JPA直接生成删除SQL：

void deleteByCarId(Long carId);

这种方式不会涉及实体对象的修改，从根源避免car_id被设置为null的问题。

方案2：手动强制flush事务上下文 #

如果无法修改removeByCarId的实现，可以在调用完该方法后，手动flush JPA实体管理器，确保删除违规记录的SQL立即执行，再执行删除车辆的操作：

@Autowired
private EntityManager entityManager;

@Transactional
@Override
public void removeById(Long id) {
    violationService.removeByCarId(id);
    // 强制flush，确保删除违规记录的SQL优先执行
    entityManager.flush();
    repository.deleteById(id);
}

方案3：配置级联删除（更简洁的方案） #

在Car实体类中，对关联的Violation集合配置级联删除，这样删除车辆时会自动删除对应的违规记录，无需手动调用violationService.removeByCarId：

@Entity
public class Car {
    // 其他字段...
    @OneToMany(mappedBy = "car", cascade = CascadeType.REMOVE, orphanRemoval = true)
    private List<Violation> violations;
    // getter/setter...
}

此时服务层方法可简化为：

@Transactional
@Override
public void removeById(Long id) {
    repository.deleteById(id);
}

这种方式由ORM处理关联删除，事务逻辑更清晰，也不会出现顺序问题。

额外排查点 #

• 检查violationService.removeByCarId是否自带@Transactional注解，如果它的事务传播行为是REQUIRES_NEW，可能导致事务上下文切换引发异常；
• 确认数据库外键约束：如果violations表的car_id是外键但未配置ON DELETE CASCADE，先删车辆会触发外键约束错误，而非非空约束，所以你的问题更可能是ORM层面的实体状态修改导致的。

内容的提问来源于stack exchange，提问作者Andrzej Jankowski