jdbc事務隔離級別主要是用在併發的情況下
jdbc事務隔離級別：（各個資料庫不一樣，以下級別遞增）
1、transaction_none 表示不支援事務，這個就不解釋了
2、transaction_read_uncommitted 允許看到未提交事務，也就是說會出現髒讀
a更新了一條記錄，但是還未提交事務，這時b檢視同一張表能夠看到a更新的資料，當然要是之後a提交了事務，那不會造成太大問題，但是萬一a在b查詢到這條更新的資料 後又回滾了事務，那麼也就是說實際上沒有更新這條資料，但是b卻讀到了這條資料，這就是所謂髒讀，要解決髒讀，使用下乙個事務隔離級別
3、transaction_read_committed 讀提交（大部分資料庫預設是這個,oracle,sqlserver）
只有當事務提交之後更新的資料才能被其他事務讀取到，自然避免了髒讀，但是還是有乙個問題，舉個現實的例子：a查到他的銀行賬戶裡有2000塊錢，但是這時他的妻子b在 網上轉賬，將這2000元錢轉出了，這時a想要刷卡消費，卻顯示餘額不足，a很奇怪：明明有錢的呀？ 問題出在**？就是因為a開啟了乙個事務之後，他的妻子又開啟了乙個 事務，而且妻子開啟的事務在a之前修改了資料庫。那麼要怎麼解決？請看下乙個級別
4、transaction_repeatable_read 讀重複(mysql預設是這個，安全級別真高。。)
針對讀提交出現的「不可重複讀」問題，只需要在a開啟乙個事務後，其他人開啟的事務無法對資料進行修改就可以了。
但是這還是存在乙個問題：其他人是無法進行修改了，但是要是a修改了，而其他人正好在查詢呢？比如a查詢後發現銀行卡中有2000元，這時他妻子也進行查詢這個月的消費情 況是1000元，然後a又進行了消費，消費1000元，然後妻子列印憑條的時候發現消費了2000元，妻子很奇怪。。。。。。也就是說讀重複只是控制了除第乙個開啟事務以外的其 他使用者修改，但是要是反過來呢？第乙個開啟事務的使用者是可以修改的，要是他修改了會造成其他使用者的幻讀
5、transaction_serializable 序列化
級別最高，事務順序執行。。。。
以上的事務級別順序提高，安全性自然是越來越提高，但是效率顯然也是越來越低
資料庫事務隔離級別
資料庫事務的隔離級別有4個，由低到高依次為read uncommitted read committed repeatable read serializable，這四個級別可以逐個解決髒讀 不可重複讀 幻讀這幾類問題。可能出現 不會出現 髒讀不可重複讀 幻讀read uncommitted rea...
資料庫事務隔離級別
資料庫事務的隔離級別有4個，由低到高依次為read uncommitted read committed repeatable read serializable，這四個級別可以逐個解決髒讀 不可重複讀 幻讀這幾類問題。可能出現 不會出現 髒讀不可重複讀 幻讀read uncommitted rea...
資料庫事務隔離級別
資料庫事務的隔離級別有4個，由低到高依次為read uncommitted read committed repeatable read serializable 這四個級別可以逐個解決髒讀 不可重複讀 幻讀 這幾類問題。可能出現 不會出現 髒讀不可重複讀 幻讀read uncommitted re...