全看使用习惯

我们碰到过引用的 mysql 连接池满了， 重启服务以后就好了，，可能应用配置的连接池满了，拿不到连接了，但是 navicat 连接不走应用连接池所以没问题？

是不是给 goland 分配的内存太小了

@SilenceLL 看起来跟楼上的朋友说的一样，如果 mq 异常，会导致事务处理过程持有锁的时间边长，影响数据库吞吐量。

@yeqizhang 嗯嗯，还是文档没有看透测 https://github.com/apache/rocketmq/blob/master/docs/cn/design.md

比如这样子：

public class Test {
@Transactional
public void createOrder() {
execCreateOrder();
sendHalfMessage();
commitCreateOrder();
}

@RocketMQTransactionListener
static class OrderTransactionListenerImpl implements RocketMQLocalTransactionListener {

@Autowired
private OrderService orderService;

@Override
public RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg) {
log.info("----executeLocalTransaction----{}", msg.getHeaders().get(RocketMQHeaders.TRANSACTION_ID, String.class));
return RocketMQLocalTransactionState.COMMIT;
}

@Override
public RocketMQLocalTransactionState checkLocalTransaction(Message msg) {
log.info("----checkLocalTransaction----{}", msg.getHeaders().get(RocketMQHeaders.TRANSACTION_ID, String.class));
String keys = msg.getHeaders().get(RocketMQHeaders.TRANSACTION_ID, String.class);
Order order = orderService.query(orderId);
if (null == order) {
return RocketMQLocalTransactionState.UNKNOWN;
}
return RocketMQLocalTransactionState.COMMIT;
}
}
}

是基于失败的成本考虑吗？如果先发 half 消息失败成本低。如果先提交事务再发送 half 消息导致事务回滚成本高。

感谢各位热心解答 @zhgg0 @yeqizhang @fkname.

如果我把发送 half 消息放在一个事物中，比如下单的事物，确保发送 half 消息成功。
然后在 TransactionListener 的 executeLocalTransaction 方法中直接返回 LocalTransactionState.COMMIT,
在 checkLocalTransaction 中检查下单的事物是否已经提交成功。这种方式有什么问题吗？