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

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

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

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

传统Spring体系结构的正确答案是将事务语义放在服务类上，原因其他人已经描述过了。

An emerging trend in Spring is toward domain-driven design (DDD). Spring Roo exemplifies the trend nicely. The idea is to make the domain object POJOs a lot richer than they are on typical Spring architectures (usually they are anemic), and in particular to put transaction and persistence semantics on the domain objects themselves. In cases where all that's needed is simple CRUD operations, the web controllers operate directly on the domain object POJOs (they're functioning as entities in this context), and there's no service tier. In cases where there's some kind of coordination needed between domain objects, you can have a service bean handle that, with @Transaction as per tradition. You can set the transaction propagation on the domain objects to something like REQUIRED so that the domain objects use any existing transactions, such as transactions that were started at the service bean.

从技术上讲，这种技术使用了AspectJ和<context:spring-configured />。Roo使用AspectJ类型间定义将实体语义(事务和持久性)与领域对象(基本上是字段和业务方法)分离开来。

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

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

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

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

服务层中的@事务使用是通过使用控制器层(@Controller)调用的，服务层调用DAO层(@Repository)，即数据库相关的操作。

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

最好将@Transactional放在DAO和服务层之间的单独中间层中。 由于回滚非常重要，您可以将所有的DB操作放在中间层，并在服务层中编写业务逻辑。中间层将与DAO层交互。

这将帮助您在许多情况下，如ObjectOptimisticLockingFailureException -此异常只发生在您的事务结束后。所以，你不能在中间层捕获它，但你现在可以在服务层捕获它。如果在服务层中有@Transactional，这是不可能的。虽然你可以在控制器中捕获，但控制器应该尽可能干净。

如果您在完成所有保存、删除和更新选项后在单独的线程中发送邮件或短信，您可以在中间层事务完成后在服务中执行此操作。同样，如果你在服务层提到@Transactional，即使你的事务失败，你的邮件也会被发送。

所以有一个中间的@Transaction层将有助于使你的代码更好，更容易处理。否则, 如果在DAO层使用，可能无法回滚所有操作。 如果在服务层使用，在某些情况下可能必须使用AOP(面向方面编程)。