为什么我们不应该让Spring MVC控制器@Transactional？

Question

已经有一些关于这个主题的问题，但是没有任何回应真正提供论据来解释为什么我们不应该制作一个Spring html" target="_blank">MVC控制器Transactional。见：

>

对于web MVC，Spring应用程序是否应在控制器或服务上运行@Transactional？

制作Spring 3 MVC控制器的方法Transactional

springmvc控制器

那么，为什么呢？

• 是否存在无法克服的技术问题
• 是否存在架构问题
• 是否存在性能/死锁/并发问题
• 有时需要多个单独的交易吗？如果是，用例是什么？（我喜欢这种简化的设计，即调用服务器要么完全成功，要么完全失败。这听起来是一种非常稳定的行为）

背景：几年前，我在一个团队工作，开发一个用C#/NHibernate/Spring实现的相当大的企业资源规划软件。网。到服务器的往返完全是这样实现的：事务在进入任何控制器逻辑之前被打开，在退出控制器后被提交或回滚。事务在框架中进行管理，这样就没有人需要关心它。这是一个出色的解决方案：稳定、简单，只有少数架构师需要关心事务问题，团队的其他成员只需实现功能。

在我看来，这是我见过的最好的设计。当我试图用SpringMVC复制相同的设计时，我陷入了一场噩梦，出现了延迟加载和事务问题，每次都得到了相同的答案：不要使控制器具有事务性，但为什么？

提前感谢您的回答！

Answer 1

有时，当抛出异常时，您希望回滚事务，但同时您希望处理异常，在控制器中创建适当的响应。

更新：回滚也可以通过编程实现，如Rodério的回答中所述。

更好的解决方案是使服务方法具有事务性，然后处理控制器方法中可能出现的异常。

下面的示例显示了具有 createUser方法的用户服务，该方法负责创建用户并向用户发送电子邮件。如果发送邮件失败，我们希望回滚用户创建：

 
  @Service
public class UserService {

    @Transactional
    public User createUser(Dto userDetails) {

        // 1. create user and persist to DB

        // 2. submit a confirmation mail
        //    -> might cause exception if mail server has an error

        // return the user
    }
}

 

然后在控制器中，您可以将对 createUser的调用包装在try/catch中，并创建对用户的正确响应：

 
  @Controller
public class UserController {

    @RequestMapping
    public UserResultDto createUser (UserDto userDto) {

        UserResultDto result = new UserResultDto();

        try {

            User user = userService.createUser(userDto);

            // built result from user

        } catch (Exception e) {
            // transaction has already been rolled back.

            result.message = "User could not be created " + 
                             "because mail server caused error";
        }

        return result;
    }
}

 

如果您在控制器方法上放置了一个 @事务，这是不可能的。

Answer 2

我在实践中见过这两种情况，在中大型商业web应用程序中，使用各种web框架（JSP/Struts 1.x、GWT、JSF 2，以及JavaEE和Spring）。

根据我的经验，最好在最高级别（即“控制器”级别）划分事务。

在一种情况下，我们有一个扩展Struts'`````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````/commit/rollback，以及将异常映射到用户友好的错误消息。如果任何异常被传播到这个级别，或者如果它被标记为只进行回滚，这个方法将简单地回滚当前事务；否则，它将提交事务。这在每种情况下都有效，通常整个HTTP请求/响应周期只有一个数据库事务。需要多个事务的罕见情况将在特定于用例的代码中处理。

在GWT-RPC的例子中，一个类似的解决方案是由一个基本GWT Servlet实现实现的。

对于JSF2，到目前为止，我只使用了服务级别划分（使用自动具有“必需”事务传播的EJB会话bean）。与在JSF支持bean级别划分事务相比，这里存在一些缺点。基本上，问题是在许多情况下JSF控制器需要进行几个服务调用，每个调用都要访问应用程序数据库。对于服务级别事务，这意味着几个单独的事务（除非发生异常，否则所有事务都已提交），这会加重数据库服务器的负担。不过，这不仅仅是性能上的劣势。一个请求/响应有多个事务也可能导致微妙的错误（我不再记得细节了，只是发生了这样的问题）。

这个问题的其他答案谈到“识别数据库/业务事务范围所需的逻辑”。这个论点对我来说没有意义，因为通常根本没有与事务划分相关的逻辑。控制器类和服务类都不需要实际“知道”事务。在绝大多数情况下，在Web应用中，每个业务操作都发生在HTTP请求/响应对中，事务的范围是从收到请求到完成响应的所有单独操作。

有时，业务服务或控制器可能需要以特定方式处理异常，然后可能仅将当前事务标记为回滚。在JavaEE（JTA）中，这是通过调用UserTransaction#setRollback Only（）来完成的。可以将UserTransaction对象注入到@Resources字段中，或者以编程方式从某些ThreadLocal中获得。在Spring中，@Transactional注释允许为某些异常类型指定回滚，或者代码可以获得线程本地TransactionState并调用setRollback Only（）。

因此，根据我的观点和经验，使控制器具有事务性是更好的方法。

Answer 3

TLDR：这是因为只有应用程序中的服务层具有标识数据库/业务事务范围所需的逻辑。控制器和持久层在设计上不能/不应该知道事务的范围。

控制器可以设置为事务性的，但实际上，通常建议只设置服务层事务性（持久层也不应该是事务性的）。

这样做的原因不是技术可行性，而是关注点的分离。控制器的职责是获取参数请求，然后调用一个或多个服务方法，并将结果组合成响应，然后发送回客户端。

因此，控制器具有协调请求执行的功能，并将域数据转换为客户端可以使用的格式，例如DTO。

业务逻辑驻留在服务层上，持久性层只是从数据库中来回检索/存储数据。

数据库事务的范围实际上是一个商业概念，也是一个技术概念：在账户转移中，只有当另一个账户被记入贷方时，账户才能被记入借方。，所以只有包含业务逻辑的服务层才能真正知道的范围银行账户转账交易。

持久层无法知道它在哪个事务中，例如方法customerDao。保存地址。它是否应该始终在自己的单独事务中运行？没有办法知道，这取决于调用它的业务逻辑。有时它应该在单独的事务上运行，有时仅在saveCustomer也工作时保存它的数据，等等。

这同样适用于控制器：saveCustomer和saveErrorMessages是否应进入同一事务？您可能希望保存客户，如果保存失败，则尝试保存一些错误消息并向客户端返回正确的错误消息，而不是回滚所有内容，包括要保存在数据库上的错误消息。

在非事务控制器中，从服务层返回的方法返回分离的实体，因为会话已关闭。这是正常的，解决方案是使用OpenSessionInView或执行查询，以获取控制器知道它需要的结果。

话虽如此，使控制器具有事务性并不是犯罪，只是不是最常用的做法。