在測試
cobar
的過程中發現了乙個問題，就是當乙個
session
執行了lock table *** write後,
其他session
包括該session
都查詢不了其他表了，直到有乙個
session
執行了unlock tables
；簡例如下：
session1:
mysql> create table t (id int primary key)engine=innodb;
query ok, 0 rows affected (0.08 sec)
session2:
lock table t write;
session1:
mysql> select * from sbtest limit 1;
error 1100 (hy000): table 'sbtest' was not locked with lock tables
session2:
unlock tables or quit;
session1:
can select other tables;
但是不同的
session
卻可以保證事務的隔離性，這是為什麼呢？其實答案就在這句話裡；
預設情況下
mysql
的autocommit=1
，並且使用
cobar
預設情況是初始化乙個共享後端連線；
當乙個session
執行lock table write
返回後，這個後端連線會被釋放到連線池裡（
mysqlchannel
）等待被重用，這時如果再有其他
session
執行查詢的話拿到的連線其實是
lock tablewrite
的狀態，所以才有上面的那個現象； 要
work around
也很簡單，就是在執行
lock tablewrite
之前執行
setautocommit=0
，這樣這個連線不會釋放回去直到提交；
乙個關於 的謎題
乙個關於 的謎題 今天在看書過程中發現了乙個問題，還挺有意思的，分享給大家。下面兩個 python 表示式會產生什麼結果？t 1,2,3,4 t 2 5,6 給四個備選答案 t變成 1,2,3,4,5,6 因為 tuple 不支援對它的元素賦值，所以會丟擲typeerror異常。以上兩個都不是。以上...
關於乙個加法優化的乙個地方
include include include base.h int main int argc,char argv,char envp 下面是彙編 01291000 55 push ebp 01291001 8bec mov ebp,esp 01291003 56 push esi 0129100...
乙個關於兔子的故事
前段時間和乙個朋友聊天，酒席間向我抱怨他那段時間的鬱悶 專案經理從客戶那裡拿來乙個需求，實際上就是乙個ppt描述，我這個朋友拿過來看後剛開始不覺得什麼，乙個通常的 系統又能複雜的了哪去，但是越往後做就越發覺得裡面的問題。在ppt描述中很多地方描述的都有矛盾。比如論壇，沒錯，小公司，尤其是對於我們這樣...