总的来说，我同意其他人的说法，事务通常在服务级别上启动(当然，这取决于您需要的粒度)。

然而，与此同时，我也开始在我的DAO层(以及其他不允许启动事务但需要现有事务的层)中添加@Transactional(propagation = propagation . mandatory)，因为当您忘记在调用者(例如服务)中启动事务时，检测错误要容易得多。如果您的DAO带有强制传播注释，则会得到一个异常，说明在调用方法时没有活动事务。

我还进行了一个集成测试，在该测试中，我检查了所有bean (bean后处理器)的该注释，如果在不属于服务层的bean中存在传播方式不是Mandatory的@Transactional注释，则会失败。这样可以确保我们不会在错误的层上启动事务。

我认为事务属于服务层。它了解工作单元和用例。如果将几个dao注入到需要在单个事务中协同工作的服务中，这是正确的答案。

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

传统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放在DAO和服务层之间的单独中间层中。 由于回滚非常重要，您可以将所有的DB操作放在中间层，并在服务层中编写业务逻辑。中间层将与DAO层交互。

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

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

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

用于数据库级别的事务

大多数情况下，我在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(..);
    }
}