服务层是添加@Transactional注释的最佳位置，因为这里呈现的大多数业务逻辑都包含细节级用例行为。

假设我们将它添加到DAO，从服务调用2个DAO类，一个失败，另一个成功，在这种情况下，如果@Transactional不在服务上，一个DB将提交，另一个DB将回滚。

因此，我的建议是明智地使用这个注释，只在服务层使用。

Github项目- java-algos

最好把它放在服务层!这在我昨天看到的一篇文章中有清楚的解释!这是你可以查看的链接!

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

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

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

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

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

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

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

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

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

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

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

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