JPA Repository层@Transactional注解的使用场景、必要性及性能影响

先看你提到的代码示例：

public interface DeviceRepository extends 
 JpaRepository<Device, Long>, JpaSpecificationExecutor<Device> {
 
    @Transactional
    void deleteDeviceByDeviceName(String deviceName);
 }

下面针对你的三个疑问逐一解答：

1. Repository层加@Transactional有必要吗？ #

得看具体调用场景：

• Spring Data JPA自带的CRUD方法（比如deleteById、save），框架已经默认给它们加了@Transactional，不用自己再加。但自定义的Repository方法就不一样了：
  • 如果这个方法是被已经开了事务的上层方法（比如Service层带@Transactional的方法）调用，那Repository层的注解就是多余的——事务会从上往下传播，直接复用就行。
  • 但如果是被没开事务的方法直接调用（比如你说的那个异步服务方法，如果它自己没加@Transactional），那这个注解就必须加。因为JPA的所有数据库操作都得在事务上下文里运行，没事务的话会直接抛出异常。

你这个场景里，要是异步方法没开事务，那同事加的这个注解就是必要的，不然调用时会报错。

2. 会影响性能吗？ #

正常合理使用的话，基本不会有明显性能损耗，但要注意几个细节：

• 事务本身确实有一点开销，比如数据库要处理事务的开始、提交，还要记录事务日志，但这点开销在常规业务场景下完全可以忽略。
• 要是传播行为设错了（比如乱用REQUIRES_NEW），会强制新建独立事务，额外增加事务创建和提交的开销。但默认的REQUIRED传播行为是合理的——有现成事务就复用，没有才新建，不会多产生额外负担。
• 另外别把Repository方法的事务范围搞太大，比如把一堆不相关的操作塞到一个方法的事务里，会导致事务占用数据库连接的时间变长，影响连接池的利用率。

3. 哪些场景适合在Repository层加@Transactional？ #

• 自定义方法被无事务的上层调用：比如直接在Controller、异步任务、定时任务里调用Repository方法，上层没开事务，这时候必须加注解，否则JPA操作无法执行。
• 需要独立事务的操作：比如某些场景下，不管上层事务成功还是失败，这个Repository方法的操作必须完成。比如记录操作日志，哪怕上层业务回滚，日志也要存下来，这时候可以给Repository方法加@Transactional(propagation = Propagation.REQUIRES_NEW)，强制开启独立事务。
• 批量操作优化：比如自定义的批量删除、批量插入方法，在Repository层加事务能让整个批量操作在一个事务里完成，既保证原子性（要么全成功要么全失败），又减少多次提交事务的开销。

内容的提问来源于stack exchange，提问作者Anil Nivargi