使用goframeORM组件进行事务操作比较简便,可以通过两种操作方式来实现。

  1. 一种是开启事务之后会返回一个事务操作对象*gdb.TX,随后可以使用该对象进行如之前章节介绍的方法操作和链式操作。
  2. 一种是以闭包的形式来操作事务,所有的事务逻辑在闭包中实现。

接口文档: https://godoc.org/github.com/gogf/gf/database/gdb#TX

Begin/Commit/Rollback

开启事务操作可以通过执行db.Begin方法,该方法返回事务的操作对象,类型为*gdb.Tx,通过该对象执行后续的数据库操作,并可通过tx.Commit提交修改,或者通过tx.Rollback回滚修改。

常见问题注意:开启事务操作后,请务必在不需要使用该事务对象时,通过Commit/Rollback操作关闭掉该事务,建议充分利用好defer方法。如果事务使用后不关闭,在应用侧会引起goroutine不断激增泄露,在数据库侧会引起事务线程数量被打满,以至于后续的事务请求执行超时。此外,建议尽可能使用后续介绍的Transaction闭包方法来安全实现事务操作。

1. 开启事务操作

if tx, err := db.Begin(); err == nil {
    fmt.Println("开启事务操作")
}

事务操作对象可以执行所有db对象的方法,具体请参考 API文档

2. 事务回滚操作

if tx, err := db.Begin(); err == nil {
    r, err := tx.Save("user", gdb.Map{
        "id"   :  1,
        "name" : "john",
    })
    tx.Rollback()
    fmt.Println(r, err)
}

3. 事务提交操作

if tx, err := db.Begin(); err == nil {
    r, err := tx.Save("user", gdb.Map{
        "id"   :  1,
        "name" : "john",
    })
    tx.Commit()
    fmt.Println(r, err)
}

4. 事务链式操作

事务操作对象仍然可以通过tx.Table或者tx.From方法返回一个链式操作的对象,该对象与db.Table或者db.From方法返回值相同,只不过数据库操作在事务上执行,可提交或回滚。

if tx, err := db.Begin(); err == nil {
    r, err := tx.Table("user").Data(gdb.Map{"id":1, "name": "john_1"}).Save()
    tx.Commit()
    fmt.Println(r, err)
}

其他链式操作请参考 ORM链式操作(重点) 章节。

Transaction闭包操作

为方便安全执行事务操作,gdb提供了事务的闭包操作,通过Transaction方法实现,该方法定义如下:

func (db DB) Transaction(f func(tx *TX) error) (err error)

当给定的闭包方法返回的errornil时,那么闭包执行结束后当前事务自动执行Commit提交操作;否则自动执行Rollback回滚操作。

如果闭包内部操作产生panic中断,该事务也将进行回滚。

使用示例:

db.Transaction(func(tx *gdb.TX) error {
    // user
    result, err := tx.Insert("user", g.Map{
        "passport": "john",
        "password": "12345678",
        "nickname": "JohnGuo",
    })
    if err != nil {
        return err
    }
    // user_detail
    id, err := result.LastInsertId()
    if err != nil {
        return err
    }
    _, err = tx.Insert("user_detail", g.Map{
        "uid":       id,
        "site":      "https://johng.cn",
        "true_name": "GuoQiang",
    })
    if err != nil {
        return err
    }
    return nil
})

嵌套事务操作

GoFrame版本v1.15.7开始,提供了对数据库嵌套事务的支持。需要注意的是,数据库服务往往并不支持嵌套事务,而是依靠ORM组件层通过Transaction Save Point特性实现的。相关方法:

// Begin starts a nested transaction procedure. 
func (tx *TX) Begin() error

// Commit commits current transaction.
// Note that it releases previous saved transaction point if it's in a nested transaction procedure,
// or else it commits the hole transaction.
func (tx *TX) Commit() error

// Rollback aborts current transaction.
// Note that it aborts current transaction if it's in a nested transaction procedure,
// or else it aborts the hole transaction.
func (tx *TX) Rollback() error

// SavePoint performs `SAVEPOINT xxx` SQL statement that saves transaction at current point.
// The parameter `point` specifies the point name that will be saved to server.
func (tx *TX) SavePoint(point string) error

// RollbackTo performs `ROLLBACK TO SAVEPOINT xxx` SQL statement that rollbacks to specified saved transaction.
// The parameter `point` specifies the point name that was saved previously.
func (tx *TX) RollbackTo(point string) error

// Transaction wraps the transaction logic using function `f`.
// It rollbacks the transaction and returns the error from function `f` if
// it returns non-nil error. It commits the transaction and returns nil if
// function `f` returns nil.
//
// Note that, you should not Commit or Rollback the transaction in function `f`
// as it is automatically handled by this function.
func (tx *TX) Transaction(f func(tx *TX) error) (err error)

1. 基本操作

一个简单的示例SQL,包含两个字段idname

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL COMMENT '用户ID',
  `name` varchar(45) NOT NULL COMMENT '用户名称',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

示例程序代码:

tx, err := db.Begin()
if err != nil {
	panic(err)
}
if err = tx.Begin(); err != nil {
	panic(err)
}
_, err = tx.Model(table).Data(g.Map{"id": 1, "name": "john"}).Insert()
if err = tx.Rollback(); err != nil {
	panic(err)
}
_, err = tx.Model(table).Data(g.Map{"id": 2, "name": "smith"}).Insert()
if err = tx.Commit(); err != nil {
	panic(err)
}

db.Begintx.Begin

可以看到,在我们的嵌套事务中出现了db.Begintx.Begin两种事务开启方式,两者有什么区别呢?db.Begin是在数据库服务上真正开启一个事务操作,并返回一个事务操作对象tx,随后所有的事务操作都是通过该tx事务对象来操作管理。tx.Begin表示在当前事务操作中开启嵌套事务,默认情况下会对嵌套事务的SavePoint采用自动命名,命名格式为transactionN,其中的N表示嵌套的层级数量,如果您看到日志中出现SAVEPOINT `transaction1`表示当前嵌套层级为2(从0开始计算)。

更详细的日志

goframeORM拥有相当完善的日志记录机制,如果您打开SQL日志,那么将会看到以下日志信息,展示了整个数据库请求的详细执行流程:

2021-05-02 13:40:15.483 [DEBU] [  0 ms] [default] SAVEPOINT `transaction0`
2021-05-02 13:40:15.485 [DEBU] [  2 ms] [default] SHOW FULL COLUMNS FROM `user`
2021-05-02 13:40:15.486 [DEBU] [  0 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-02 13:40:15.486 [DEBU] [  0 ms] [default] ROLLBACK TO SAVEPOINT `transaction0`
2021-05-02 13:40:15.486 [DEBU] [  0 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-02 13:40:15.487 [DEBU] [  1 ms] [default] COMMIT

执行后查询数据库结果:

mysql> select * from `user`;
+----+-------+
| id | name  |
+----+-------+
|  2 | smith |
+----+-------+
1 row in set (0.00 sec)

可以看到第一个操作被成功回滚,只有第二个操作执行并提交成功。

2. 闭包操作

我们也可以通过闭包操作来实现嵌套事务,同样也是通过Transaction方法实现。

Transaction方式可以实现对嵌套事务操作的无限层级嵌套,但是不推荐层级过深的嵌套事务,否则业务逻辑上可能不太好维护。本示例演示的是只有一个层级的事务嵌套操作。

if err = db.Transaction(func(tx *gdb.TX) error {
	// Nested transaction 1.
	if err = tx.Transaction(func(tx *gdb.TX) error {
		_, err = tx.Model(table).Data(g.Map{"id": 1, "name": "john"}).Insert()
		return err
	}); err != nil {
		return err
	}
	// Nested transaction 2, panic.
	if err = tx.Transaction(func(tx *gdb.TX) error {
		_, err = tx.Model(table).Data(g.Map{"id": 2, "name": "smith"}).Insert()
		// Create a panic that can make this transaction rollback automatically.
		panic("error")
	}); err != nil {
		return err
	}
	return nil
}); err != nil {
	panic(err)
}

这个示例中,最后的事务执行失败之后,所有的操作都将会回滚。执行后,什么数据都不会写入。如果您打开SQL日志,那么将会看到以下日志信息,展示了整个数据库请求的详细执行流程:

2021-05-02 13:42:01.935 [DEBU] [  1 ms] [default] SAVEPOINT `transaction0`
2021-05-02 13:42:01.939 [DEBU] [  4 ms] [default] SHOW FULL COLUMNS FROM `user`
2021-05-02 13:42:01.940 [DEBU] [  0 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-02 13:42:01.940 [DEBU] [  0 ms] [default] RELEASE SAVEPOINT `transaction0`
2021-05-02 13:42:01.940 [DEBU] [  0 ms] [default] SAVEPOINT `transaction0`
2021-05-02 13:42:01.941 [DEBU] [  0 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-02 13:42:01.941 [DEBU] [  0 ms] [default] ROLLBACK TO SAVEPOINT `transaction0`
2021-05-02 13:42:01.941 [DEBU] [  0 ms] [default] ROLLBACK

3. SavePoint/RollbackTo

开发者也可以灵活使用Transaction Save Point特性,并实现自定义的SavePoint命名以及指定Point回滚操作。

tx, err := db.Begin()
if err != nil {
	panic(err)
}
defer func() {
	if err := recover(); err != nil {
		_ = tx.Rollback()
	}
}()
if _, err = tx.Model(table).Data(g.Map{"id": 1, "name": "john"}).Insert(); err != nil {
	panic(err)
}
if err = tx.SavePoint("MyPoint"); err != nil {
	panic(err)
}
if _, err = tx.Model(table).Data(g.Map{"id": 2, "name": "smith"}).Insert(); err != nil {
	panic(err)
}
if _, err = tx.Model(table).Data(g.Map{"id": 3, "name": "green"}).Insert(); err != nil {
	panic(err)
}
if err = tx.RollbackTo("MyPoint"); err != nil {
	panic(err)
}
if err = tx.Commit(); err != nil {
	panic(err)
}

如果您打开SQL日志,那么将会看到以下日志信息,展示了整个数据库请求的详细执行流程:

2021-05-02 13:59:36.788 [DEBU] [  3 ms] [default] SHOW FULL COLUMNS FROM `user`
2021-05-02 13:59:36.788 [DEBU] [  0 ms] [default] INSERT INTO `user`(`name`,`id`) VALUES('john',1) 
2021-05-02 13:59:36.789 [DEBU] [  1 ms] [default] SAVEPOINT `MyPoint`
2021-05-02 13:59:36.789 [DEBU] [  0 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-02 13:59:36.789 [DEBU] [  0 ms] [default] INSERT INTO `user`(`name`,`id`) VALUES('green',3) 
2021-05-02 13:59:36.789 [DEBU] [  0 ms] [default] ROLLBACK TO SAVEPOINT `MyPoint`
2021-05-02 13:59:36.791 [DEBU] [  2 ms] [default] COMMIT

执行后查询数据库结果:

mysql> select * from `user`;
+----+------+
| id | name |
+----+------+
|  1 | john |
+----+------+
1 row in set (0.00 sec)

可以看到,通过在第一个Insert操作后保存了一个SavePoint名称MyPoint,随后的几次操作都通过RollbackTo方法被回滚掉了,因此只有第一次Insert操作被成功提交执行。



Content Menu

  • No labels

8 Comments

  1. 不管事务是 commit 或者 rollback,这个事务都结束了;所以获取到的事务连接 tx  不要想着保存了供后续使用

  2. 现在ORM生成的DAO,似乎无法自动完成事务嵌套。比如,最早我之前实现了一个 aService.GetInfoByID,这里面只有一个FindOne操作。然而,我需要新设计一个UpdateInfo,逻辑为更新后,再查询。而查询是调用了GetInfoByID方法。即,其实大概逻辑应该是:

    begin();

    update....

    GetInfoByID()

    ...

    commit;

    当出现这类嵌套需求时,对于GetInfoByID,它其实并不知道外层会有事务调用。所以在GetInfoByID内部,其实并不会受到事务影响。这样就出现一个问题,我用GetInfoByID获取到的数据,并不是事务内更新过的数据。这样就引起了一个BUG。但是,若我想事务作用于GetInfoByID内部,那就必须传递tx进去。


    还有一种情况,存在一个Update1()的方法,其内部使用了事务。这时又需要编写一个Update2(),在Update1()的基础上,再额外增加一些其它更新操作。保证Update2的操作是事务的。但由于Update1内部已经有一个事务。那么,在Update2中开了事务后,两个嵌套事务能否一起提交与回滚?


    对于这些情况。GF有无考虑?若有考虑,那应该如何处理?

    1. 你好啊,以下是我的个人看法,欢迎交流讨论。

      1. 事务操作往往是和特定的业务场景绑定的,因此特定业务逻辑的封装方法中增加tx对象的输入是合理的。
      2. 建议通过Transaction闭包的方式来管理事务,内部会自动执行Commit或者Rollback方法。
      3. 如果是多个数据库的多个事务,涉及到分布式事务,属于架构设计,不是ORM组件能够解决的。
      1. 若是每次使用事务,都必须如此操作。那么很多业务级的方法就很难去封装及维护。经常存在某个业务逻辑,是由更小的多个业务逻辑组合而成。而为了原子性,则需要在这个业务中启用事务。

        但是,现在问题来了。若更底层的逻辑不是由当前调用者维护的,这些方法的内部处理对外则是透明的。若我想实现所有底层的业务处理完毕,再统一提交事务,这样就很困难了。因为现在没办法在更高层逻辑中开启事务。

        同时,就算团队约定好每个方法必须支持事务传入,但是,这样的代码量也会增加非常多。并不利于快速开发。

        这个问题,我也一直在考虑如何在业务层能解决,但是发现,还是比较困难。可能还是需要调整ORM底层,或更换框架的使用方式(比如放弃sevice, dao的单例使用)。

        现在我是自己封装了一个 Transaction,通过获取堆栈信息来识别当前的协程ID。然后完成的嵌套处理。不过,这样依然有缺陷,主要问题还是,若子方法中的Transaction未覆盖所有数据库操作,那么这些操作将不会被加入上一级的事务操作中。比如我们的一个子逻辑为“先查询,再事务更新”。在父逻辑中,是会执行 事务更新数据后再调用这个子逻辑(事务中调用)。这样子逻辑中由于查询未在事务中,则会导致查出来的数据出现不一致,引起逻辑BUG。思来想去,还是只有ORM底层改造能解决这个问题。


        1. 大概明白你的意思了,你这个痛点确实只有从orm入手才能解决。

          这个时候service的对象不能使用dao的数据对象了,而是应当动态生成service对象,service依赖的dao对象应当支持依赖注入,这样才能满足你的要求。不过如何优雅的设计可能会比较麻烦,你可以提个issue,我后续考虑下这个改进,你也可以直接在goframe的个人空间上写个wiki文章描述你的设计,我们一起讨论。

  3. 事务嵌套确实有必要支持,项目维护的人稍微一多,事务嵌套就避免不了,要是不支持事务嵌套,会带来很大麻烦,可以参考一下 laravel 是怎么处理事务嵌套的

  4. 事务嵌套,是在子事务开启时设置还原点,需保证是同一个连接

     SAVEPOINT  name1

    在子嵌套事务中回滚,就是回滚到还原点
    ROLLBACK TO SAVEPOINT name1

    commit提交时全部提交