CodeIgniter框架中關于DB事務處理的設計缺陷

來源：懂視網責編：小采時間：2020-11-09 13:16:18

CodeIgniter框架中關于DB事務處理的設計缺陷

CodeIgniter框架中關于DB事務處理的設計缺陷:起因：在我們線上的某個業務中，使用較老版本的CodeIgniter框架，其中的DB類中，對DB事物處理部分存在著一個設計上的缺陷，或許也算不上缺陷吧。但他卻影響了我們生產環境，導致連鎖反應。對業務產生較大影響，且不容易排查。這個問題，我在今年的3月中旬，

推薦度：

點擊下載本文 文檔為doc格式

導讀CodeIgniter框架中關于DB事務處理的設計缺陷:起因：在我們線上的某個業務中，使用較老版本的CodeIgniter框架，其中的DB類中，對DB事物處理部分存在著一個設計上的缺陷，或許也算不上缺陷吧。但他卻影響了我們生產環境，導致連鎖反應。對業務產生較大影響，且不容易排查。這個問題，我在今年的3月中旬，

起因：在我們線上的某個業務中，使用較老版本的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.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;

同時，這個類的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) = 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 //開始事務處理
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 //執行其他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) = 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 //執行其他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) = 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 //執行其他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) = 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 //回滾事務 #注意看這里
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 //恢復自動提交
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時間點處，發送更新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事務處理的設計缺陷, 感謝原作者分享。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

CodeIgniter框架中關于DB事務處理的設計缺陷

推薦度：

點擊下載本文 文檔為doc格式

標簽：處理設計關于

熱門焦點

CodeIgniter框架中關于DB事務處理的設計缺陷

CodeIgniter框架中關于DB事務處理的設計缺陷

CodeIgniter框架中關于DB事務處理的設計缺陷

最新推薦

猜你喜歡

熱門推薦