spring事物問題，及解決過程。

寫的很差，但願多多指教。

 

問題：java程序斷點執行中update操做後不更新數據庫。

 

問題結果：

當java程序中在執行涉及事物的update操做中，不能操做事物中的表。

(READ-COMMITTED事務隔離級別，只有在事務提交後，纔會對另外一個事務產生影響，而且在對錶進行修改時，會對錶數據行加上行共享鎖！)。

 

問題現象：

當程序斷點執行前，對數據庫進行查詢操做：結果

程序斷點執行完update操做後結果：

 

解決過程：

在java程序斷點執行後從日誌中找出對應的參數以及sql語句，複製到mysqlIDE中執行

 

mysqlIDE 執行過程：

 

mysqlIDE 執行結果：

 

 

 mysqlIDE沒法執行更新操做，根據執行結果內容查找：

進入MySql數據庫進入  命令行模式

經過執行  select @@tx_isolation;查看數據庫的隔離級別結果：發現該表被鎖住了。

 

 

 

關於MySql 數據庫的READ-COMMITTED事物隔級別介紹以及小demo：

READ-COMMITTED（讀取提交內容）

　　1）設置A的事務隔離級別，並進入事務作一次查詢

　　　

 

　　2）B開始事務，並對記錄進行修改

　　　

 

　　3）A再對user表進行查詢，發現記錄沒有受到影響

　　　

 

　　4）B提交事務

　　　

 

　　5）A再對user表查詢，發現記錄被修改

　　　

 

　　6）A對user表進行修改

　　　

 

　　7）B從新開始事務，並對user表同一條進行修改，發現修改被掛起，直到超時，但對另外一條記錄修改，倒是成功，說明A的修改對user表加上了行共享鎖(由於能夠select)

　　　

　　　

 

　　READ-COMMITTED事務隔離級別，只有在事務提交後，纔會對另外一個事務產生影響，而且在對錶進行修改時，會對錶數據行加上行共享鎖！

 

 

 

 

 

 

 

 

 

順便摟草打兔子：

 

說說修改事務隔離級別的方法：

1.全局修改，修改mysql.ini配置文件，在最後加上

1 #可選參數有：READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. 2 [mysqld] 3 transaction-isolation = REPEATABLE-READ

這裏全局默認是REPEATABLE-READ,其實MySQL原本默認也是這個級別

2.對當前session修改，在登陸mysql客戶端後，執行命令：

set session transaction isolation level read uncommitted;

 

要記住mysql有一個autocommit參數，默認是on，他的做用是每一條單獨的查詢都是一個事務，而且自動開始，自動提交（執行完之後就自動結束了，若是你要適用select for update，而不手動調用 start transaction，這個for update的行鎖機制等於沒用，由於行鎖在自動提交後就釋放了），因此事務隔離級別和鎖機制即便你不顯式調用start transaction，這種機制在單獨的一條查詢語句中也是適用的，分析鎖的運做的時候必定要注意這一點

 

鎖機制：
共享鎖：由讀表操做加上的鎖，加鎖後其餘用戶只能獲取該表或行的共享鎖，不能獲取排它鎖，也就是說只能讀不能寫

排它鎖：由寫表操做加上的鎖，加鎖後其餘用戶不能獲取該表或行的任何鎖，典型是mysql事務中

start transaction;

select * from user where userId = 1 for update;

執行完這句之後

　　1）當其餘事務想要獲取共享鎖，好比事務隔離級別爲SERIALIZABLE的事務，執行

　　select * from user;

 　　將會被掛起，由於SERIALIZABLE的select語句須要獲取共享鎖

　　2）當其餘事務執行

　　select * from user where userId = 1 for update;

　　update user set userAge = 100 where userId = 1; 

　　也會被掛起，由於for update會獲取這一行數據的排它鎖，須要等到前一個事務釋放該排它鎖才能夠繼續進行

 

鎖的範圍:

行鎖: 對某行記錄加上鎖

表鎖: 對整個表加上鎖

這樣組合起來就有,行級共享鎖,表級共享鎖,行級排他鎖,表級排他鎖

 

READ-UNCOMMITTED(讀取未提交內容)級別

　　1)A修改事務級別並開始事務，對user表作一次查詢

　　　

 

　　2)B更新一條記錄

　　　

 

　　3）此時B事務還未提交，A在事務內作一次查詢，發現查詢結果已經改變

　　　

 

　　4）B進行事務回滾

　　　

 

　　5）A再作一次查詢，查詢結果又變回去了

　　　

 

　　6）A表對user表數據進行修改

　　　

 

　　7）B表從新開始事務後，對user表記錄進行修改，修改被掛起，直至超時，可是對另外一條數據的修改爲功，說明A的修改對user表的數據行加行共享鎖(由於可使用select)

　　　

 

　　能夠看出READ-UNCOMMITTED隔離級別，當兩個事務同時進行時，即便事務沒有提交，所作的修改也會對事務內的查詢作出影響，這種級別顯然很不安全。可是在表對某行進行修改時，會對該行加上行共享鎖！

 

 

 

REPEATABLE-READ(可重讀)

　　1）A設置事務隔離級別，進入事務後查詢一次

　　　

 

　　2）B開始事務，並對user表進行修改

　　　

 

　　3）A查看user表數據，數據未發生改變

　　　

 

　　4）B提交事務

　　　

 

　　5）A再進行一次查詢，結果仍是沒有變化

　　　

 

　　6）A提交事務後，再查看結果，結果已經更新

　　　

 

　　7）A從新開始事務，並對user表進行修改

　　　

　　　

　　8）B表從新開始事務，並對user表進行修改，修改被掛起，直到超時，對另外一條記錄修改卻成功，說明A對錶進行修改時加了行共享鎖(能夠select)

　　　

　　　

 

　　REPEATABLE-READ事務隔離級別，當兩個事務同時進行時，其中一個事務修改數據對另外一個事務不會形成影響，即便修改的事務已經提交也不會對另外一個事務形成影響。

　　在事務中對某條記錄修改，會對記錄加上行共享鎖，直到事務結束纔會釋放！

 

4.SERIERLIZED(可串行化)

　　1）修改A的事務隔離級別，並做一次查詢

　　　

 

　　2）B對錶進行查詢，正常得出結果，可知對user表的查詢是能夠進行的

　　　

 

　　3）B開始事務，並對記錄作修改，由於A事務未提交，因此B的修改處於等待狀態，等待A事務結束，最後超時，說明A在對user表作查詢操做後，對錶加上了共享鎖

　　　

 

　　SERIALIZABLE事務隔離級別最嚴厲，在進行查詢時就會對錶或行加上共享鎖，其餘事務對該表將只能進行讀操做，而不能進行寫操做！