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

  1. 一种是Begin开启事务之后会返回一个事务操作对象*gdb.TX,随后可以使用该对象进行如之前章节介绍的方法操作和链式操作。
  2. 一种是以Transaction闭包方法的形式来操作事务,所有的事务逻辑在闭包中实现,并且支持非常便捷的嵌套事务,嵌套事务在业务操作中透明无感知。

我们推荐事务操作均统一采用Transaction闭包方式实现。

接口文档: 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", g.Map{
        "id"   :  1,
        "name" : "john",
    })
    if err != nil {
        tx.Rollback()
    }
    fmt.Println(r)
}

3. 事务提交操作

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

4. 事务链式操作

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

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

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

Transaction闭包操作

可以看到,通过常规的事务方法来管理事务有很多重复性的操作,并且存在遗忘提交/回滚操作来关闭事务的风险,因此为方便安全执行事务操作,ORM组件同样提供了事务的闭包操作,通过Transaction方法实现,该方法定义如下:

func (db DB) Transaction(ctx context.Context, f func(ctx context.Context, tx *TX) error) (err error)

当给定的闭包方法返回的errornil时,那么闭包执行结束后当前事务自动执行Commit提交操作;否则自动执行Rollback回滚操作。闭包中的context.Context参数为goframe v1.16版本后新增的上下文变量,主要用于链路跟踪传递以及嵌套事务管理。由于上下文变量是嵌套事务管理的重要参数,因此上下文变量通过显示的参数传递定义。

如果闭包内部操作产生panic中断,该事务也将自动进行回滚,以保证操作安全。

使用示例:

db.Transaction(context.TODO(), func(ctx context.Context, tx *gdb.TX) error {
	// user
	result, err := tx.Ctx(ctx).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.Ctx(ctx).Insert("user_detail", g.Map{
		"uid":       id,
		"site":      "https://johng.cn",
		"true_name": "GuoQiang",
	})
	if err != nil {
		return err
	}
	return nil
})

Transaction嵌套事务

goframe版本v1.16版本开始,提供了对数据库嵌套事务的支持。需要注意的是,数据库服务往往并不支持嵌套事务,而是依靠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(ctx context.Context, f func(ctx context.Context, tx *TX) error) (err error)

同样的,我们推荐使用Transaction闭包方法来实现嵌套事务操作。为了保证文档的完整性,因此我们这里仍然从最基本的事务操作方法开始来介绍嵌套事务操作。

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-22 21:12:10.776 [DEBU] [  4 ms] [default] [1] BEGIN
2021-05-22 21:12:10.776 [DEBU] [  0 ms] [default] [1] SAVEPOINT `transaction0`
2021-05-22 21:12:10.789 [DEBU] [ 13 ms] [default] [1] SHOW FULL COLUMNS FROM `user`
2021-05-22 21:12:10.790 [DEBU] [  1 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-22 21:12:10.791 [DEBU] [  1 ms] [default] [1] ROLLBACK TO SAVEPOINT `transaction0`
2021-05-22 21:12:10.791 [DEBU] [  0 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-22 21:12:10.792 [DEBU] [  1 ms] [default] [1] COMMIT

其中的[1]表示ORM组件记录的事务ID,多个真实的事务同时操作时,每个事务的ID将会不同。在同一个真实事务下的嵌套事务的事务ID是一样的。

执行后查询数据库结果:

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

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

2. 闭包操作

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

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

嵌套事务的闭包嵌套中也可以不使用其中的tx对象,而是直接使用db对象或者dao包,这种方式更常见一些。特别是在方法层级调用时,使得对于开发者来说并不用关心tx对象的传递,也并不用关心当前事务是否需要嵌套执行,一切都由组件自动维护,极大减少开发者的心智负担。但是务必记得将ctx上下文变量层层传递下去哦。例如:

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

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

2021-05-22 21:18:46.672 [DEBU] [  2 ms] [default] [1] BEGIN
2021-05-22 21:18:46.672 [DEBU] [  0 ms] [default] [1] SAVEPOINT `transaction0`
2021-05-22 21:18:46.673 [DEBU] [  0 ms] [default] [1] SHOW FULL COLUMNS FROM `user`
2021-05-22 21:18:46.674 [DEBU] [  0 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-22 21:18:46.674 [DEBU] [  0 ms] [default] [1] RELEASE SAVEPOINT `transaction0`
2021-05-22 21:18:46.675 [DEBU] [  1 ms] [default] [1] SAVEPOINT `transaction0`
2021-05-22 21:18:46.675 [DEBU] [  0 ms] [default] [1] INSERT INTO `user`(`name`,`id`) VALUES('smith',2) 
2021-05-22 21:18:46.675 [DEBU] [  0 ms] [default] [1] ROLLBACK TO SAVEPOINT `transaction0`
2021-05-22 21:18:46.676 [DEBU] [  1 ms] [default] [1] ROLLBACK

假如ctx上下文变量没有层层传递下去,那么嵌套事务将会失败,我们来看一个错误的例子:

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

打开SQL执行日志,执行后,您将会看到以下日志内容:

2021-05-22 21:29:38.841 [DEBU] [  3 ms] [default] [1] BEGIN
2021-05-22 21:29:38.842 [DEBU] [  1 ms] [default] [1] SAVEPOINT `transaction0`
2021-05-22 21:29:38.843 [DEBU] [  1 ms] [default] [1] SHOW FULL COLUMNS FROM `user`
2021-05-22 21:29:38.845 [DEBU] [  2 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-22 21:29:38.845 [DEBU] [  0 ms] [default] [1] RELEASE SAVEPOINT `transaction0`
2021-05-22 21:29:38.846 [DEBU] [  1 ms] [default] [1] SAVEPOINT `transaction0`
2021-05-22 21:29:38.847 [DEBU] [  1 ms] [default] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-22 21:29:38.848 [DEBU] [  0 ms] [default] [1] ROLLBACK TO SAVEPOINT `transaction0`
2021-05-22 21:29:38.848 [DEBU] [  0 ms] [default] [1] ROLLBACK

可以看到,第二条INSERT操作没有事务ID打印,表示没有使用到事务,那么该操作将会被真正提交到数据库执行,并不能被回滚。

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-22 21:38:51.992 [DEBU] [  3 ms] [default] [1] BEGIN
2021-05-22 21:38:52.002 [DEBU] [  9 ms] [default] [1] SHOW FULL COLUMNS FROM `user`
2021-05-22 21:38:52.002 [DEBU] [  0 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(1,'john') 
2021-05-22 21:38:52.003 [DEBU] [  1 ms] [default] [1] SAVEPOINT `MyPoint`
2021-05-22 21:38:52.004 [DEBU] [  1 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(2,'smith') 
2021-05-22 21:38:52.005 [DEBU] [  1 ms] [default] [1] INSERT INTO `user`(`id`,`name`) VALUES(3,'green') 
2021-05-22 21:38:52.006 [DEBU] [  0 ms] [default] [1] ROLLBACK TO SAVEPOINT `MyPoint`
2021-05-22 21:38:52.006 [DEBU] [  0 ms] [default] [1] COMMIT

执行后查询数据库结果:

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

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

嵌套事务在工程中的参考示例

为了简化示例,我们还是使用用户模块相关的示例,例如用户注册,通过事务操作保存用户基本信息(user)、详细信息(user_detail)两个表,任一个表操作失败整个注册操作都将失败。为展示嵌套事务效果,我们将用户基本信息管理和用户详细信息管理划分为了两个dao对象。

假如我们的项目按照goframe标准项目工程化分为三层api-service-dao,那么我们的嵌套事务操作可能是这样的。

api

// 用户注册HTTP接口
func (*userApi) Signup(r *ghttp.Request) {
	// ....
	service.User.Signup(r.Context(), userServiceSignupReq)
	// ...
}

承接HTTP请求,并且将Context上下文边变量传递给后续的流程。

service

// 用户注册业务逻辑处理
func (*userService) Signup(ctx context.Context, r *model.UserServiceSignupReq) {
	// ....
	dao.User.Transaction(ctx, func(ctx context.Context, tx *gdb.TX) error {
		err := dao.User.Ctx(ctx).Save(r.UserInfo)
		if err != nil {
			return err
		}
		err := dao.UserDetail.Ctx(ctx).Save(r.UserDetail)
		if err != nil {
			return err
		}
		return nil
	})
	// ...
}

可以看到,内部的user表和user_detail表使用了嵌套事务来统一执行事务操作。注意在闭包内部需要通过Ctx方法将上下文变量传递给下一层级。假如在闭包中存在对其他service对象的调用,那么也需要将ctx变量传递过去,例如:

func (*userService) Signup(ctx context.Context, r *model.UserServiceSignupReq) {
	// ....
	dao.User.Transaction(ctx, func(ctx context.Context, tx *gdb.TX) error {
		err := dao.User.Ctx(ctx).Save(r.UserInfo)
		if err != nil {
			return err
		}
		err := dao.UserDetail.Ctx(ctx).Save(r.UserDetail)
		if err != nil {
			return err
		}
		err := service.XXXA.Call(ctx, ...)
		if err != nil {
			return err
		}
		err := service.XXXB.Call(ctx, ...)
		if err != nil {
			return err
		}
		err := service.XXXB.Call(ctx, ...)
		if err != nil {
			return err
		}
        // ...
		return nil
	})
	// ...
}

dao

dao层的代码由goframe cli工具全自动化生成即可。





Content Menu

  • No labels

17 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文章描述你的设计,我们一起讨论。

            1. 已改进,v1.16新版不再需要显示传递tx参数,但是需要层级传递ctx上下文变量。

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

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

     SAVEPOINT  name1

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

    commit提交时全部提交

    1. 已支持嵌套事务。

  5. func (db DB) Transaction(ctx context.Context, f func(ctx context.Context, tx *TX) error) (err error)

    从 v1.15 升级到 v1.16,发现 Transaction 多了 context.Context 参数。


    问:实践当中这个 ctx 哪里来?

    从 controller 层的 *ghttp.Request  一路传过来吗?这样的话,整个调用链的参数都要改,成本太大了

    但默认的  context.TODO() 和 context.Background()  又是全局共用的,似乎不太适合http服务(看到有人说即使从它俩继承也不太好)

    求解

    1. 推荐是从顶层即r.Context()返回的ctx层级传递到下层。如果实在不想用ctx,就传递默认的context.TODO()或者context.Background() 。此外,其实GoFrame ORMCtx方法也支持nil,不过Go官方不推荐使用nil传递ctx,程序处理不好可能会在某些场景产生意想不到的问题。做Go项目你会发现将第一个参数设置为ctx参数是一个很好的习惯,项目越到后面你会发现越有必要,特别是针对于微服务项目来说。

  6. 有一个拼写小错误,第四行Transaction少写了一个i

  7. 提一个建议,建议考虑通过ctx传递tx对象,因为经常在使用事务的时候需要这样写:
    dao.XXX.Ctx(ctx).Tx(tx).MethodXXX()

    希望通过ctx传递的tx之后,只需要这样使用就可以:

    ctx := context.WithValue(ctx, "tx", tx)

    dao.XXX.Ctx(ctx).MethodXXX()

    1. 本来使用Transaction闭包就不需要显示调用Tx方法传递事务对象,原本就注入到ctx中了的。