前言
我们在开发一个复杂的系统时可能经常出现这样的场景:比如,A函数中调用了B函数,而A函数和B函数同时都使用了事务,这样就出现了事务嵌套。在MySQL的官方文档中有明确的说明MySQL是不支持嵌套事务的:
Transactions cannot be nested. This is a consequence of the implicit commit performed for any current transaction when you issue a START TRANSACTION statement or one of its synonyms.
那我们该如何解决MySQL的事务嵌套问题呢?
解决方法
目前,在PHP圈有两种比较通用的解决方法,一种是以Doctrine为代表的,设置回滚点的解决方法,一种是以Laravel为代表的,控制事务次数的解决方法。
Doctrine的解决方法
Doctrine解决方法的核心就是对回滚点的控制,如下:
Doctrine中开启事务的方法
Doctrine中事务回滚的方法
Doctrine中事务提交的方法
Doctrine用一个_transactionNestingLevel来标识当前嵌套的级别,如果是1,也就是还没有嵌套,那就用默认的方法执行一下START TRANSACTION就ok了;如果大于1,也就是有嵌套的时候,它会帮我们创建一个savepoint。这个savepoint可以理解为一个事务记录点,当需要回滚时我们可以只回滚到这个点。
Laravel的解决方法
相对Doctrine而言,Laravel的解决方法稍微简单粗暴,它巧妙的使用了一个 transactions属性来记录了调用事务的次数。在事务开启,事务提交和事务回滚时,先判断transactions的属性值,只有当transactions的属性值为1时,才进行事务操作。如下:
在开启事务时,我们先判断当前有几个事务,如果是***个,ok,事务开始,否则就啥都不做。
在事务提交时,也判断当前事务个数,如果是***个,ok,提交事务,否则,就只将transactions属性值减一
在事务回滚时,同样先判断当前事务个数,如果是***个,ok,回滚事务,同时将transactions属性值置为0,否则,就只将transactions属性值减一。
在Laravel的解决方法中,在嵌套的内层里面实际上是木有真正的事务的,只有最外层一个整体的事务,虽然简单粗暴,但是也解决了在内层新建一个事务时会造成commit的问题。