原因：
在我们的一项在线业务中，使用了旧版本的 CodeIgniter 框架。 DB类中，DB事务处理部分存在设计缺陷，看上去并不是缺陷。 但他却影响了我们的生产环境，造成了连锁反应。 对业务影响较大，且不易排查。 我在去年3月下旬向站长Hex报告了这个问题，然后我就忘记了。 直到明天我们线上业务又想到了这个问题，所以又查了一下。 具体原因，大家先让我慢慢说完。 （最新版本Version2.1.0也存在此问题）
分析：
以CodeIgniter框架Version2.1.0为例，systemdatabaseDB_driver.php中CI_DB_driver类的第58行有一个$_trans_status属性。
//systemdatabaseDB_driver.php var $trans_strict = TRUE; var $_trans_depth = 0; var $_trans_status = TRUE; // Used with transactions to determine if a rollback should occur var $cache_on = FALSE;
同时，该类的查询方法中，有分配重合属性的代码，见文件第306行和第307行
// This will trigger a rollback if transactions are being used $this->_trans_status = FALSE;
这里也给出了注释，告诉我们如果使用事务处理，那么这个属性就会成为回滚的判定条件。
在交易提交方法trans_complete第520行，如下代码
/**
* Complete Transaction
*
* @access public
* @return bool
*/
function trans_complete()
{
if ( ! $this->trans_enabled)
{
return FALSE;
}
// When transactions are nested we only begin/commit/rollback the outermost ones
if ($this->_trans_depth > 1)
{
$this->_trans_depth -= 1;
return TRUE;
}
// The query() function will set this flag to FALSE in the event that a query failed
if ($this->_trans_status === FALSE)
{
$this->trans_rollback();
// If we are NOT running in strict mode, we will reset
// the _trans_status flag so that subsequent groups of transactions
// will be permitted.
if ($this->trans_strict === FALSE)
{
$this->_trans_status = TRUE;
}
log_message('debug', 'DB Transaction Failure');
return FALSE;
}
$this->trans_commit();
return TRUE;
}
第535行php 事务处理，如果_trans_status属性为false，则会发生回滚，但会返回false。
在我们的业务代码中，由于程序员的疏忽，他没有判断trans_complete()方法是否执行正确，直接告诉用户操作成功，但实际上程序已经向trans_complete()方法发出了回滚指令。 DB，并且数据库记录未成功更新。 当用户执行下一步操作时，程序发现对应的记录尚未更新，提醒用户之前的操作尚未完成php 事务处理，并通知用户重新执行。 如此反复...
CodeIgniter框架的设计缺陷
调查过程也很有趣。 本来，从PHP代码中，始终无法确定问题所在，焦点也不在trans_complete()方法的返回上。 直到strace抓包分析后才知道回滚是这个属性造成的。
22:54:08.380085 write(9, "_3UPDATE `cfc4n_user_info` SET `cfc4n_user_lock` = 1nWHERE `cfc4n_user_id` = '6154'nAND `cfc4n_user_lock` = 0", 99) = 99 //执行更新命令
22:54:08.380089 read(9, ":1377364#42S22Unknown column 'cfc4n_user_lock' in 'where clause'", 16384) = 62 //不存在字段，SQL执行错误
22:54:08.381791 write(9, "213SET AUTOCOMMIT=0", 21) = 21 //禁止自动提交
22:54:08.381891 read(9, "71", 16384) = 11
22:54:08.382186 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 0) = 0
22:54:08.382258 write(9, "v2jv01_roles", 15) = 15
22:54:08.382343 read(9, "71", 16384) = 11
22:54:08.382631 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 0) = 0
22:54:08.382703 write(9, "223START TRANSACTION", 22) = 22 //开始事务处理
22:54:08.401954 write(9, "v2database_demo", 15) = 15
22:54:08.402043 read(9, "7111", 16384) = 11
22:54:08.417773 write(9, "v2database_demo", 15) = 15
22:54:08.417872 read(9, "711", 16384) = 11
22:54:08.418256 write(9, "[3UPDATE `cfc4n_user_info` SET `silver` = CAST( silver + (5) as signed )nWHERE `cfc4n_user_id` = '6154'", 95) = 95 //执行其他SQL语句
22:54:08.418363 read(9, "0111(Rows matched: 1 Changed: 1 Warnings: 0", 16384) = 52 //成功更新，影响条数1.
22:54:08.430212 write(9, "v2database_demo", 15) = 15
22:54:08.430314 read(9, "711", 16384) = 11
22:54:08.430698 write(9, "B3UPDATE `cfc4n_user_info` SET `exp` = exp + 26nWHERE `cfc4n_user_id` = '6154'", 70) = 70 //执行其他SQK语句
22:54:08.430814 read(9, "0111(Rows matched: 1 Changed: 1 Warnings: 0", 16384) = 52 //成功更新，影响条数1.
22:54:08.432130 write(9, "v2database_demo", 15) = 15
22:54:08.432231 read(9, "711", 16384) = 11
22:54:08.432602 write(9, "2443UPDATE `cfc4n_user_quest` SET `rew` = 1, `retable` = retable + 1, `re_time` = 1335797648nWHERE `cfc4n_user_id` = '6154'nAND `quest_id` = '300001'nAND `rew` = 0", 168) = 168 //执行其他SQK语句
22:54:08.432743 read(9, "0111(Rows matched: 1 Changed: 1 Warnings: 0", 16384) = 52 //成功更新，影响条数1.
22:54:08.433517 write(9, "v2database_demo", 15) = 15
22:54:08.433620 read(9, "711", 16384) = 11
22:54:08.433954 write(9, "t3ROLLBACK", 13) = 13 //回滚事务 #注意看这里
22:54:08.434041 read(9, "71", 16384) = 11
22:54:08.434914 write(9, "v2database_demo", 15) = 15
22:54:08.434999 read(9, "71", 16384) = 11
22:54:08.435342 write(9, "213SET AUTOCOMMIT=1", 21) = 21 //恢复自动提交
22:54:08.435430 read(9, "712", 16384) = 11
22:54:08.436923 write(9, "11", 5) = 5
可以看到，在22:54:08.380085时间点，发送更新SQL语句命令，在22:54:08.380089时间点读取返回结果，得到SQL执行错误，数组“cfc4n_user_lock”不存在； 22:54:08.381791和22:54:08.382703两个时间点，PHP发送停止“自动提交”和“开始事务处理”命令，并在22:54:08.433954发送“事务回滚”命令。
通过上面的代码分析，可以清楚的知道，$_trans_status属性设置为FALSE，代码提交事务时，通过trans_complete()方法判断，感觉有SQL语句执行失败“最后一笔交易”（下面会仔细分析），所以决定回滚交易，不提交。
刚才我们讲了“最后一个事务处理”，有的同学可能不太明白，我们先回到代码，继续看这个属性，同样在trans_complete方法中，第542-545行：
// If we are NOT running in strict mode, we will reset
// the _trans_status flag so that subsequent groups of transactions
// will be permitted.
if ($this->trans_strict === FALSE)
{
$this->_trans_status = TRUE;
}
从评论中也很容易理解，设置CI的设计者设置CI是为了处理得更严格。 当同一个脚本中有多个事务时，事务之间的关系很重要。 这里的 trans_strict 属性是一个开关。 当trans_strict为false时，为非严格模式，表示多个事务之间的关系不重要，互不影响。 当前事务中，有SQL语句执行失败，不会对你造成影响。 _trans_status 设置为 TRUE。
毫无疑问，这是一个非常深思熟虑的考虑。 考虑多个事务之间的关系，保证业务运行在更严谨的代码上。
然而，在我们的代码中，错误的SQL语句是在事务外执行的，而不是在事务内执行的。 基于我们对事务的理解，我们可以清楚地了解到事务外的SQL比事务内的SQL更重要。 事务外的SQL是允许出错的，但事务内的SQL一定不能出错，必须是正确的，不受外界干扰。 然而在CI框架中，由于执行事务以外的一句话失败，导致整个事务被回滚……当然，我们程序员并没有对事务提交方式的返回做出决定，也就是也是一个问题。
问题已经很清楚了，所以解决方案对你来说一定很简单。
例如，在trans_start方法中，将_trans_status属性参数设置为TRUE，忽略事务之外的问题。
function trans_start($test_mode = FALSE)
{
if ($this->trans_strict === FALSE)
{
$this->_trans_status = TRUE; //在开始事务处理时，重新设定这个属性的值为TRUE
}
//2012/05/01 18:00 经过CI中文社区网友 http://codeigniter.org.cn/forums/space-uid-5721.html指正，这里修改为增加trans_strict 属性判断 ，在决定是否重设_trans_status 为好。
if ( ! $this->trans_enabled)
{
return FALSE;
}
// When transactions are nested we only begin/commit/rollback the outermost ones
if ($this->_trans_depth > 0)
{
$this->_trans_depth += 1;
return;
}
$this->trans_begin($test_mode);
}
结束：
在不了解对方的设计意图的情况下，无论程序作者的水平如何，都不能盲目地定义对方的代码评估。 如果你比自己强大，你就不能盲目崇拜他们； 如果你比自己弱，你就不能随意批评别人；如果你比自己弱，你就不能随意批评别人。 分析理解设计意图，学习别人优秀的设计思想、编码风格、算法效率，是一个好习惯。 事实上，codeigniter 框架非常优秀。
CFC4N 的博客是根据 Creative Commons Attribution-Noncommercial-ShareAlike（3.0 Unlocalized）许可证创作和许可的。 基于上述创作作品。转载请注明出处：CodeIgniter框架中DB事务处理的设计缺陷
还没有相关文章
