聊聊数据库事务内嵌TCP连接

最近再看项目代码，发现很多的service里面，喜欢在事务内部再去调用HTTP请求，简单分析下此种方式的利弊与解决策略。

概述

在数据库内部嵌套TCP连接(一般是HTTP调用或是RPC远程调用)。

@Transactional(rollbackFor = Exception.class)
public Boolean inviteUser(..){
    // service 调用
    userService.add(..);
	// HTTP调用
    httpClient.post(..,20)
}

优点：

1. 保障两个操作间的原子性、隔离性。
2. 事务控制： 建立TCP连接可以使数据库管理系统更好地控制和监视事务。它可以跟踪连接的状态和事务的执行进度，从而更容易实现事务管理和恢复。
3. 性能优化： 内部TCP连接可以针对特定的事务进行性能优化。例如，可以为事务分配更多的系统资源，以提高其执行速度。
4. 安全性： 内部TCP连接可以通过加密和认证来增强安全性，确保只有授权的用户或应用程序能够访问数据库

弊端：

1. TCP连接可能会超时，导致事务变成长事务。
2. 网络抖动出现异常，可能会导致前一个正常的操作回滚。
3. 资源消耗： 每个TCP连接都需要消耗系统资源，包括内存和处理能力。在高负载情况下，内部建立TCP连接可能导致资源耗尽，影响其他事务的执行。
4. 连接维护开销： 维护大量的TCP连接可能会增加数据库管理系统的开销。每个连接都需要管理、维护和监视，这可能会导致性能下降。
5. 复杂性： 内部TCP连接引入了更复杂的架构，需要更多的管理和维护工作。这可能需要更多的开发和管理工作，并增加了系统的复杂性。
6. 连接延迟： 建立和维护TCP连接需要时间，这可能会导致事务的启动延迟。对于需要快速响应的事务，这可能是一个不利因素。

解决方案

评估审视多个操作调用之间是否有强一致性。

1. 有强一致性
   必须手动开启事务，根据HTTP调用的返回码进行手动事务提交或回滚。事务传播级别，尽量使用当前事务。
   增加一个查询的动作，用于检索RPC的操作是否正常进行。

2. 无强一致性

   手动开启事务，或是使用自动事务注解，但最后可以通过事件监听器回调事务接口的afterCommit方法，再进行HTTP调用。事务传播级别，尽量使用当前事务。