传统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类型间定义将实体语义(事务和持久性)与领域对象(基本上是字段和业务方法)分离开来。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

用于数据库级别的事务

大多数情况下，我在DAO的方法级别上使用@Transactional，所以配置可以专门用于一个方法/使用默认值(必需的)

DAO获取数据的方法(select ..)-不需要 @事务性这可能会导致一些开销，因为 事务拦截器/和需要执行的AOP代理 好。 DAO的插入/更新方法将获得@Transactional

非常好的博客

应用级别: 我正在使用事务性业务逻辑，我希望能够在发生意外错误的情况下回滚

@Transactional(rollbackFor={MyApplicationException.class})
public void myMethod(){

    try {    
        //service logic here     
    } catch(Throwable e) {

        log.error(e)
        throw new MyApplicationException(..);
    }
}