我将@Transactional放在@Service层，并设置rollbackFor任何异常和readOnly以进一步优化事务。

默认情况下@Transactional将只查找RuntimeException(未检查的异常)，通过将回滚设置为exception. class(已检查的异常)，它将回滚任何异常。

@Transactional(readOnly = false, rollbackFor = Exception.class)

参见已检查异常和未检查异常。

@Transactional注释应该放在所有不可分割的操作周围。 使用@Transactional可以自动处理事务传播。在这种情况下，如果当前方法调用了另一个方法，那么该方法将可以选择加入正在进行的事务。

让我们举个例子:

我们有两个模型，即国家和城市。国家和城市模型的关系映射就像一个国家可以有多个城市，所以映射就像，

@OneToMany(fetch = FetchType.LAZY, mappedBy="country")
private Set<City> cities;

在这里国家映射到多个城市，获取他们懒惰。这里是@Transactinal的作用当我们从数据库中检索Country对象时，我们会得到Country对象的所有数据，但不会得到城市的集合，因为我们是懒洋洋地获取城市。

//Without @Transactional
public Country getCountry(){
   Country country = countryRepository.getCountry();
   //After getting Country Object connection between countryRepository and database is Closed 
}

当我们想要从国家对象访问Set of Cities时，我们将在该Set中获得空值，因为只有该Set创建的对象没有初始化该Set的数据来获取Set的值，我们使用@Transactional，即，

//with @Transactional
@Transactional
public Country getCountry(){
   Country country = countryRepository.getCountry();
   //below when we initialize cities using object country so that directly communicate with database and retrieve all cities from database this happens just because of @Transactinal
   Object object = country.getCities().size();   
}

所以基本上@Transactional is Service可以在单个事务中进行多个调用，而无需关闭与端点的连接。

通常情况下是在服务层级别上注释，但这实际上取决于您的需求。

在服务层上注释将比在DAO层上注释产生更长的事务。这取决于事务隔离级别，可以产生问题，因为并发事务不会看到彼此的更改，例如。可重复读。

在dao上注释将使事务尽可能简短，缺点是您的服务层公开的功能不会在单个(可回滚的)事务中完成。

如果传播模式被设置为默认，那么对两个层都进行注释就没有意义了。

或者对两个“层”都加注释有意义吗?-同时标注服务层和dao层不是很有意义吗-如果你想确保dao方法总是从服务层调用(传播)，并且在dao中传播是“强制的”。这将为DAO方法从UI层(或控制器)调用提供一些限制。此外——特别是在对DAO层进行单元测试时——对DAO进行注释还将确保对其事务功能进行测试。

我更喜欢在方法级的服务层上使用@Transactional。

事务注释应该放在所有不可分割的操作周围。

例如，你的呼叫是“change password”。它由两个操作组成

修改密码。 审计变更。 通过电子邮件通知客户端密码已更改。

那么在上面，如果审计失败，那么修改密码也应该失败吗?如果是这样，那么事务应该在1和2左右(因此在服务层)。如果电子邮件失败了(可能应该有某种故障安全措施，这样它就不会失败)，那么它是否应该回滚更改密码和审计?

在决定将@Transactional放在哪里时，您需要询问这些问题。