Golang Go语言中，大佬们请教个问题，正在使用 gorm 有些必要弄个事务提交成功后回调的工具吗？

发布于 1周前 作者 songsunli 来自 Go语言

为什么有这个疑问呢，因为这似乎是个少用的工具，gorm也不支持。都是又觉得有必要，在一些场景下可能会用到，例如在服务层的方法中向消息队列发布消息，这显然是要在事务成功提交后发布的。 实现大致方向是封装事务方法，在context中写一个值来存储回调方法。


Golang Go语言中，大佬们请教个问题，正在使用 gorm 有些必要弄个事务提交成功后回调的工具吗？
Harmonyos Next教程
9 回复

想复杂了吧哥,这两个异构中间件就正常业务流程写就好了吧, tx 提交后再调用 mq

更多关于Golang Go语言中，大佬们请教个问题，正在使用 gorm 有些必要弄个事务提交成功后回调的工具吗？的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


没必要这么花里胡哨，你这样也保证不了一致性。还不如保持存储层简单干净，消息逻辑里发就行。

这不是一个少用的工具，而是一个性化的需求。

消息大多在服务层发送，就是事务有些是接口层控制的

主要是框架导致，使用了子事务，导致服务层的事务提交不一定是最终提交。

但是 gorm 的 Transaction 方法可以开启子事务，当前事务的提交不一定代表最终提交，所以想着需不需要这样的工具，或通过其他方式。

用 outbox 模式，把消息也写到 db 。

非常感谢，拓宽了我的眼界，outbox 模式是我现在所知道的最佳解决方案。

在Golang中使用Gorm进行数据库操作时，是否需要使用事务提交成功后的回调工具，主要取决于你的具体需求和业务逻辑复杂度。

首先，事务的主要目的是确保一系列数据库操作要么全部成功，要么在遇到错误时全部回滚，以保持数据的一致性。Gorm已经提供了对事务的良好支持，你可以通过Begin(), Commit(), Rollback()等方法来管理事务。

对于事务提交成功后的回调，如果你的业务逻辑需要在事务成功提交后执行一些额外的操作（比如发送通知、更新缓存等），那么使用回调工具确实是一个不错的选择。这可以帮助你更好地组织代码，将事务操作和后续处理逻辑分离，提高代码的可读性和可维护性。

然而，需要注意的是，回调的引入也可能带来额外的复杂性和潜在的错误。比如，回调中的错误处理需要特别小心，以避免影响事务的提交结果。此外，如果回调操作本身涉及数据库操作，还需要考虑是否需要在新的事务中执行。

综上所述，是否使用事务提交成功后的回调工具，取决于你的具体需求和业务逻辑。如果确实需要，可以选择合适的回调工具，并仔细处理其中的错误和事务管理问题。如果业务逻辑相对简单，直接在事务提交后执行后续操作也是可以的。

回到顶部