DB2預設的事務及併發鎖機制

今天試驗了一下DB2的併發鎖機制，結果，還是挺讓人失望的，和MSSQL的差不多：
1、DB2的預設行為，事務以可執行的SQL開始，以COMMIT或ROLLBACK結束；
2、DB2預設是否提交，以工具的不同而不同，這也是DB2的特點，對外界環境依賴比較明顯，比如：使用者認證就是，依賴作業系統或第三方認證。
3、今天我的試驗過程是這樣：
（1）先啟動DB2CLP，db2cmd->db2
（2）連線TEST資料庫，connect to test
（3）建立一個試驗表，create table test(id int,aa varchar(10))
（4）驗證表結構，describe table test
（5）插入兩行資料，insert into test values(1,'aaaa')
                   insert into test values(2,'bbbb')
（6）驗證資料，select * from test
               h 歷史命令；
               r n 執行第n條命令；
               e n編輯第n條命令；
（7）update test set aa='cccc' where id=1
（8）啟動另一個DB2CLP,update test set aa='dddd' where id=1,結果沒什麼阻塞，大為震驚，都說ORACLE的鎖獨步天下，沒想到DB2的鎖也是獨步天下啊。回頭覺得不對勁，查了一下
DB2的文件，結果DB2是否自動提交依賴於介面或工具，那麼DB2CLP的這個選項預設是什麼呢？
（9）DB2CLP下查各種命令選項，list command options;
（10）結果選項c 預設為ON,開啟的，意味著在DB2CLP中，預設對SQL命令是自動提交的。
（11）把C 選項改為OFF，update command options using c off,注意在每個DB2CLP中都要改，因為這個命令只會影響到當前連線。
（12）修改完三個DB2CLP連線中的C 選項後，開始試驗；
（13）第一個DB2CLP中，update test set aa='eeee' where id=1;
      第二個DB2CLP中，update test set aa='ffff' where id=1;
結果阻塞；然後在第三個DB2CLP中，update test set aa='GGGG' where id=2;
也是阻塞，說明db2不帶阻塞了同行資料的修改，這是正常的，而且也阻塞了不同行但在一個
page頁中的行的修改，看來它得鎖模型也是和MSSQL一樣，屬於悲觀模型。
這段時間一直看DB2的資料，可以說受益匪淺，更把各種系統的鎖模型進行了比較，結果發現，DB2和MSSQL比較相似的，之前，我對MSSQL的鎖進行了更進一步的跟蹤，發現MSSQL對未提交事務涉及的表是加表級鎖的，這會阻塞其他事務對該事務涉及表的修改操作。同時，也會阻塞其他事務的讀操作。
而對於ORACLE和MYSQL來說，是不會產生這種表或塊級阻塞的，主要還是因為鎖模型的不同，主要還是觀念的原因吧，或者說是樂觀和悲觀的原因。談不上誰好誰壞，大家只看到了併發度，而沒看到樂觀鎖會給應用帶來的壞處，就一味的說悲觀鎖不好，不可否認ORACLE等系統的樂觀鎖會帶來系統效能上的好處，讓大家用著會舒服，可應用上的處理就會麻煩那些，這也是DB2,MSSQL始終不改變這點的原因，觀念不同而已。