@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可以在单个事务中进行多个调用，而无需关闭与端点的连接。

此外，Spring建议只在具体的类上使用注释，而不是在接口上使用。

http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html

首先，让我们定义一下在什么地方使用事务?

我认为正确的答案是——当我们需要确保动作序列将作为一个原子操作一起完成时，或者即使其中一个动作失败，也不会进行任何更改。

将业务逻辑放入服务中是众所周知的实践。因此，服务方法可能包含必须作为单个逻辑工作单元执行的不同操作。如果是，那么这种方法必须被标记为事务性的。当然，并不是每个方法都需要这样的限制，所以您不需要将整个服务标记为事务性的。

更重要的是，不要忘记考虑@Transactional可能会降低方法性能。 为了了解全局，您必须了解事务隔离级别。了解这一点可以帮助您避免在不必要的地方使用@Transactional。

通常，应该将事务放在服务层。

但是正如前面所述，操作的原子性告诉我们哪里需要注释。因此，如果你使用像Hibernate这样的框架，其中一个“save/update/delete/…”一个对象上的“modify”操作有可能修改几个表中的几行(因为通过对象图的级联)，当然在这个特定的DAO方法上也应该有事务管理。

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

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

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

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

理想情况下，服务层(管理器)表示业务逻辑，因此应该用@Transactional进行注释。服务层可以调用不同的DAO来执行DB操作。让我们假设在一个服务方法中有N个DAO操作。如果您的第一个DAO操作失败，其他DAO操作可能仍然通过，您将以不一致的DB状态结束。注释服务层可以避免这种情况。