起因：

在我們線上的某個(gè)業(yè)務(wù)中，使用較老版本的CodeIgniter框架，其中的DB類中，對(duì)DB事物處理部分存在著一個(gè)設(shè)計(jì)上的缺陷，或許也算不上缺陷吧。但他卻影響了我們生產(chǎn)環(huán)境，導(dǎo)致連鎖反應(yīng)。對(duì)業(yè)務(wù)產(chǎn)生較大影響，且不容易排查。這個(gè)問題，我在今年的3月中旬，曾向codeigniter中國的站長Hex 報(bào)告過，之后，我也忘記這件事情了。直到今天，我們線上業(yè)務(wù)又一次以為這個(gè)問題，害的我又排查一次。具體原因，各位且先聽我慢慢說完。(這個(gè)問題同樣存在于最新版本Version 2.1.0中)

分析：

以CodeIgniter框架Version 2.1.0為例，在system/database/DB_driver.php的CI_DB_driver類中第58行有個(gè)$_trans_status屬性。

復(fù)制代碼 代碼如下:
//system/database/DB_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;

同時(shí)，這個(gè)類的query方法中，有賦值此屬性的代碼，見文件306、307行
復(fù)制代碼 代碼如下:
// This will trigger a rollback if transactions are being used
$this->_trans_status = FALSE;

這里也給了注釋，告訴我們，如果使用了事物處理，那么這屬性將成為一個(gè)回滾的決定條件。

在520行的事物提交方法trans_complete中，如下代碼：
復(fù)制代碼 代碼如下:
/**
 * 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，那么將發(fā)生回滾，并且返回false。

在我們的業(yè)務(wù)代碼中，由于程序員疏忽，沒有判斷trans_complete()方法是否正確執(zhí)行，直接告訴用戶操作成功，但實(shí)際上，程序已經(jīng)向DB下達(dá)回滾指令，并未成功更新DB記錄。當(dāng)用戶執(zhí)行下一步操作時(shí)，程序又發(fā)現(xiàn)相應(yīng)記錄并未更新，又提醒用戶上個(gè)操作沒有完成，通知用戶重新執(zhí)行。如此反復(fù)…

排查的過程，也是挺有意思的，起初從php代碼中，總是不能確定問題所在，并沒有把焦點(diǎn)放到trans_complete()方法的返回上。直到后來strace抓包分析，才知道是因?yàn)榇藢傩远鴮?dǎo)致了回滾。

復(fù)制代碼 代碼如下:
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    //執(zhí)行更新命令
22:54:08.380089 read(9, ":/0/0/1/377/36/4#42S22Unknown column /'cfc4n_user_lock/' in /'where clause/'", 16384) = 62    //不存在字段，SQL執(zhí)行錯(cuò)誤
22:54:08.381791 write(9, "/21/0/0/0/3SET AUTOCOMMIT=0", 21) = 21    //禁止自動(dòng)提交
22:54:08.381891 read(9, "/7/0/0/1/0/0/0/0/0/0/0", 16384) = 11
22:54:08.382186 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 0) = 0
22:54:08.382258 write(9, "/v/0/0/0/2jv01_roles", 15) = 15
22:54:08.382343 read(9, "/7/0/0/1/0/0/0/0/0/0/0", 16384) = 11
22:54:08.382631 poll([{fd=9, events=POLLIN|POLLPRI}], 1, 0) = 0
22:54:08.382703 write(9, "/22/0/0/0/3START TRANSACTION", 22) = 22   //開始事務(wù)處理
22:54:08.401954 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.402043 read(9, "/7/0/0/1/0/0/0/1/0/1/0", 16384) = 11
22:54:08.417773 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.417872 read(9, "/7/0/0/1/0/0/0/1/0/0/0", 16384) = 11
22: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    //執(zhí)行其他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    //成功更新，影響條數(shù)1.
22:54:08.430212 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.430314 read(9, "/7/0/0/1/0/0/0/1/0/0/0", 16384) = 11
22:54:08.430698 write(9, "B/0/0/0/3UPDATE `cfc4n_user_info` SET `exp` = exp + 26/nWHERE `cfc4n_user_id` = /'6154/'", 70) = 70     //執(zhí)行其他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    //成功更新，影響條數(shù)1.
22:54:08.432130 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.432231 read(9, "/7/0/0/1/0/0/0/1/0/0/0", 16384) = 11
22: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    //執(zhí)行其他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    //成功更新，影響條數(shù)1.
22:54:08.433517 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.433620 read(9, "/7/0/0/1/0/0/0/1/0/0/0", 16384) = 11
22:54:08.433954 write(9, "/t/0/0/0/3ROLLBACK", 13) = 13    //回滾事務(wù) #注意看這里
22:54:08.434041 read(9, "/7/0/0/1/0/0/0/0/0/0/0", 16384) = 11
22:54:08.434914 write(9, "/v/0/0/0/2database_demo", 15) = 15
22:54:08.434999 read(9, "/7/0/0/1/0/0/0/0/0/0/0", 16384) = 11
22:54:08.435342 write(9, "/21/0/0/0/3SET AUTOCOMMIT=1", 21) = 21  //恢復(fù)自動(dòng)提交
22:54:08.435430 read(9, "/7/0/0/1/0/0/0/2/0/0/0", 16384) = 11
22:54:08.436923 write(9, "/1/0/0/0/1", 5) = 5

可以看到，在22:54:08.380085時(shí)間點(diǎn)處，發(fā)送更新SQL語句指令，在22:54:08.380089時(shí)間讀取返回結(jié)果，得到SQL執(zhí)行錯(cuò)誤，不存在字段”cfc4n_user_lock”；22:54:08.381791和22:54:08.382703兩個(gè)時(shí)間點(diǎn)，php發(fā)送停止“自動(dòng)提交”與“開始事務(wù)處理”指令，在 22:54:08.433954 發(fā)送“事務(wù)回滾”指令。

配合如上的代碼分析，可以清楚的知道，因?yàn)椤癠PDATE `cfc4n_user_info` SET `cfc4n_user_lock` = 1 WHERE `cfc4n_user_id` = '6154′ AND `cfc4n_user_lock` = 0”這句SQL執(zhí)行錯(cuò)誤，導(dǎo)致$_trans_status屬性被設(shè)置為FALSE，當(dāng)代碼提交事務(wù)時(shí)，被trans_complete()方法判斷，認(rèn)為“上一個(gè)事務(wù)處理”(下面將仔細(xì)分析)中存在SQL語句執(zhí)行失敗，決定回滾事務(wù)，不提交。

剛剛提到“上一個(gè)事務(wù)處理”，可能有些朋友不能理解，我們先繼續(xù)回到代碼中來，繼續(xù)看該屬性，同樣在trans_complete方法中，542-545行：

復(fù)制代碼 代碼如下:
// 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;
}

也可以很容易的從注釋中看明白，設(shè)置CI的設(shè)計(jì)者，為了更嚴(yán)謹(jǐn)?shù)奶幚?同一個(gè)腳本中，存在多個(gè)事務(wù)時(shí)，事務(wù)間彼此關(guān)系重要，一榮俱榮，一損俱損。這里的trans_strict屬性，是個(gè)開關(guān)，當(dāng) trans_strict為false，便是非嚴(yán)格模式，意味著多個(gè)事務(wù)之間，彼此關(guān)系不重要，不影響。當(dāng)前一個(gè)事務(wù)中有SQL語句執(zhí)行失敗，影響不到自己。便將_trans_status 設(shè)置為TRUE。
毫無疑問，這是個(gè)非常周全的考慮。考慮了多個(gè)事務(wù)之間的關(guān)系，保證業(yè)務(wù)跑在更嚴(yán)謹(jǐn)?shù)拇a上。

可是，我們的代碼中，錯(cuò)誤的SQL語句是執(zhí)行在事務(wù)處理以外的，并不是事務(wù)之內(nèi)。按照我們對(duì)事務(wù)的認(rèn)識(shí)，可以很清晰的知道，事務(wù)之外的SQL相比事務(wù)之內(nèi)的SQL來說，事務(wù)之內(nèi)的SQL更重要，之外的可以允許出錯(cuò)，但事務(wù)之內(nèi)的，務(wù)必要正確，不受外界干擾。但CI的框架中，因?yàn)橐粋€(gè)事務(wù)以外的語句執(zhí)行失敗，卻導(dǎo)致整個(gè)事務(wù)回滾…當(dāng)然，我們的程序員沒有對(duì)事務(wù)提交方法的返回做判斷，這也是個(gè)問題。

問題已經(jīng)很清晰了，那么解決方法想必對(duì)你來說，是多么的簡(jiǎn)單。
比如在trans_start方法中，對(duì)_trans_status 屬性賦值，設(shè)置為TRUE，不理會(huì)事務(wù)外的問題。

復(fù)制代碼 代碼如下:
function trans_start($test_mode = FALSE)
{
 if ($this->trans_strict === FALSE)
 {
  $this->_trans_status = TRUE;    //在開始事務(wù)處理時(shí)，重新設(shè)定這個(gè)屬性的值為TRUE
 }
    //2012/05/01 18:00 經(jīng)過CI中文社區(qū)網(wǎng)友 http://codeigniter.org.cn/forums/space-uid-5721.html指正，這里修改為增加trans_strict 屬性判斷 ，在決定是否重設(shè)_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);
}

結(jié)束：

在不明白對(duì)方設(shè)計(jì)意圖的情況下，不能盲目的定義對(duì)方的代碼評(píng)價(jià)，不管程序作者的水平如何。比自己強(qiáng)，也不能盲目崇拜；比自己弱，更不能亂加指責(zé)；理解讀懂設(shè)計(jì)意圖，學(xué)習(xí)他人優(yōu)秀的設(shè)計(jì)思路、代碼風(fēng)格、算法效率，這才是一個(gè)好習(xí)慣。當(dāng)然codeigniter框架是優(yōu)秀的。

php技術(shù)：CodeIgniter框架數(shù)據(jù)庫事務(wù)處理的設(shè)計(jì)缺陷和解決方案，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。