起因： 在我们线上的某个业务中，使用较老版本的codeigniter框架，其中的db类中，对db事物处理部分存在着一个设计上的缺陷，或许也算不上缺陷吧。但他却影响了我们生产环境，导致连锁反应。对业务产生较大影响，且不容易排查。这个问题，我在今年的3月中旬，
起因：
在我们线上的某个业务中，使用较老版本的codeigniter框架，其中的db类中，对db事物处理部分存在着一个设计上的缺陷，或许也算不上缺陷吧。但他却影响了我们生产环境，导致连锁反应。对业务产生较大影响，且不容易排查。这个问题，我在今年的3月中旬，曾向http://codeigniter.org.cn/的站长hex 报告过，之后，我也忘记这件事情了。直到今天，我们线上业务又一次以为这个问题，害的我又排查一次。具体原因，各位且先听我慢慢说完。(这个问题同样存在于最新版本version 2.1.0中)
分析：
以codeigniter框架version 2.1.0为例，在system\database\db_driver.php的ci_db_driver类中第58行有个$_trans_status属性。
//system\database\db_driver.phpvar $trans_strict = true;var $_trans_depth = 0;var $_trans_status = true; // used with transactions to determine if a rollback should occurvar $cache_on = false;
同时，这个类的query方法中，有赋值此属性的代码，见文件306、307行
// this will trigger a rollback if transactions are being used$this->_trans_status = false;
这里也给了注释，告诉我们，如果使用了事物处理，那么这属性将成为一个回滚的决定条件。
在520行的事物提交方法trans_complete中，如下代码
/** * 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行中，如果_trans_status属性如果是false，那么将发生回滚，并且返回false。
在我们的业务代码中，由于程序员疏忽，没有判断trans_complete()方法是否正确执行，直接告诉用户操作成功，但实际上，程序已经向db下达回滚指令，并未成功更新db记录。当用户执行下一步操作时，程序又发现相应记录并未更新，又提醒用户上个操作没有完成，通知用户重新执行。如此反复…
codeigniter框架的设计缺陷
排查的过程，也是挺有意思的，起初从php代码中，总是不能确定问题所在，并没有把焦点放到trans_complete()方法的返回上。直到后来strace抓包分析，才知道是因为此属性而导致了回滚。
22:54:08.380085 write(9, _\0\0\0\3update `cfc4n_user_info` set `cfc4n_user_lock` = 1\nwhere `cfc4n_user_id` = \'6154\'\nand `cfc4n_user_lock` = 0, 99) = 99 //执行更新命令22:54:08.380089 read(9, :\0\0\1\377\36\4#42s22unknown column \'cfc4n_user_lock\' in \'where clause\', 16384) = 62 //不存在字段，sql执行错误22:54:08.381791 write(9, \21\0\0\0\3set autocommit=0, 21) = 21 //禁止自动提交22:54:08.381891 read(9, \7\0\0\1\0\0\0\0\0\0\0, 16384) = 1122:54:08.382186 poll([{fd=9, events=pollin|pollpri}], 1, 0) = 022:54:08.382258 write(9, \v\0\0\0\2jv01_roles, 15) = 1522:54:08.382343 read(9, \7\0\0\1\0\0\0\0\0\0\0, 16384) = 1122:54:08.382631 poll([{fd=9, events=pollin|pollpri}], 1, 0) = 022:54:08.382703 write(9, \22\0\0\0\3start transaction, 22) = 22 //开始事务处理22:54:08.401954 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.402043 read(9, \7\0\0\1\0\0\0\1\0\1\0, 16384) = 1122:54:08.417773 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.417872 read(9, \7\0\0\1\0\0\0\1\0\0\0, 16384) = 1122:54:08.418256 write(9, [\0\0\0\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, 0\0\0\1\0\1\0\1\0\0\0(rows matched: 1 changed: 1 warnings: 0, 16384) = 52 //成功更新，影响条数1.22:54:08.430212 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.430314 read(9, \7\0\0\1\0\0\0\1\0\0\0, 16384) = 1122:54:08.430698 write(9, b\0\0\0\3update `cfc4n_user_info` set `exp` = exp + 26\nwhere `cfc4n_user_id` = \'6154\', 70) = 70 //执行其他sqk语句22:54:08.430814 read(9, 0\0\0\1\0\1\0\1\0\0\0(rows matched: 1 changed: 1 warnings: 0, 16384) = 52 //成功更新，影响条数1.22:54:08.432130 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.432231 read(9, \7\0\0\1\0\0\0\1\0\0\0, 16384) = 1122:54:08.432602 write(9, \244\0\0\0\3update `cfc4n_user_quest` set `rew` = 1, `retable` = retable + 1, `re_time` = 1335797648\nwhere `cfc4n_user_id` = \'6154\'\nand `quest_id` = \'300001\'\nand `rew` = 0, 168) = 168 //执行其他sqk语句22:54:08.432743 read(9, 0\0\0\1\0\1\0\1\0\0\0(rows matched: 1 changed: 1 warnings: 0, 16384) = 52 //成功更新，影响条数1.22:54:08.433517 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.433620 read(9, \7\0\0\1\0\0\0\1\0\0\0, 16384) = 1122:54:08.433954 write(9, \t\0\0\0\3rollback, 13) = 13 //回滚事务 #注意看这里22:54:08.434041 read(9, \7\0\0\1\0\0\0\0\0\0\0, 16384) = 1122:54:08.434914 write(9, \v\0\0\0\2database_demo, 15) = 1522:54:08.434999 read(9, \7\0\0\1\0\0\0\0\0\0\0, 16384) = 1122:54:08.435342 write(9, \21\0\0\0\3set autocommit=1, 21) = 21 //恢复自动提交22:54:08.435430 read(9, \7\0\0\1\0\0\0\2\0\0\0, 16384) = 1122:54:08.436923 write(9, \1\0\0\0\1, 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 发送“事务回滚”指令。
配合如上的代码分析，可以清楚的知道，因为“update `cfc4n_user_info` set `cfc4n_user_lock` = 1 where `cfc4n_user_id` = ’6154′ and `cfc4n_user_lock` = 0”这句sql执行错误，导致$_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的设计者，为了更严谨的处理 同一个脚本中，存在多个事务时，事务间彼此关系重要，一荣俱荣，一损俱损。这里的trans_strict属性，是个开关，当 trans_strict为false，便是非严格模式，意味着多个事务之间，彼此关系不重要，不影响。当前一个事务中有sql语句执行失败，影响不到自己。便将_trans_status 设置为true。
毫无疑问，这是个非常周全的考虑。考虑了多个事务之间的关系，保证业务跑在更严谨的代码上。
可是，我们的代码中，错误的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框架是优秀的。
原文地址：codeigniter框架中关于db事务处理的设计缺陷, 感谢原作者分享。