事務的幾種傳播特性
1. propagation_required: 如果存在乙個事務，則支援當前事務。如果沒有事務則開啟
2. propagation_supports: 如果存在乙個事務，支援當前事務。如果沒有事務，則非事務的執行
3. propagation_mandatory: 如果已經存在乙個事務，支援當前事務。如果沒有乙個活動的事務，則丟擲異常。
4. propagation_requires_new: 總是開啟乙個新的事務。如果乙個事務已經存在，則將這個存在的事務掛起。
5. propagation_not_supported: 總是非事務地執行，並掛起任何存在的事務。
6. propagation_never: 總是非事務地執行，如果存在乙個活動事務，則丟擲異常
7. propagation_nested：如果乙個活動的事務存在，則執行在乙個巢狀的事務中. 如果沒有活動事務,
則按transactiondefinition.propagation_required 屬性執行
事務的隔離級別
在資料庫操作中，為了有效保證併發讀取資料的正確性，提出的事務隔離級別；為了解決更新丟失，髒讀，不可重讀（包括虛讀和幻讀）等問題在標準sql規範中，定義了4個事務隔離級別，分別為未授權讀取，也稱為讀未提交（read uncommitted）；授權讀取，也稱為讀提交（read committed）；可重複讀取（repeatable read）；序列化（serializable）.
依賴注入和控制反轉
反轉是相對於正向而言的，那麼什麼算是正向的呢？考慮一下常規情況下的應用程式，如果要在a裡面使用c，你會怎麼做呢？當然是直接去建立c的物件，也就是說，是在a類中主動去獲取所需要的外部資源c，這種情況被稱為正向的。那麼什麼是反向呢？就是a類不再主動去獲取c，而是被動等待，等待ioc/di的容器獲取乙個c的例項，然後反向的注入到a類中。
用圖例來說明一下，先看沒有ioc/di的時候，常規的a類使用c類的示意圖，如圖7所示：
圖7 常規a使用c示意圖
當有了ioc/di的容器後，a類不再主動去建立c了，如圖8所示：
圖8 a類不再主動建立c
而是被動等待，等待ioc/di的容器獲取乙個c的例項，然後反向的注入到a類中，如圖9所示：
圖9 有ioc/di容器後程式結構示意圖
（9）依賴注入和控制反轉是同一概念嗎？
根據上面的講述，應該能看出來，依賴注入和控制反轉是對同一件事情的不同描述，從某個方面講，就是它們描述的角度不同。依賴注入是從應用程式的角度在描述，可以把依賴注入描述完整點：應用程式依賴容器建立並注入它所需要的外部資源；而控制反轉是從容器的角度在描述，描述完整點：容器控制應用程式，由容器反向的向應用程式注入應用程式所需要的外部資源。
（10）小結一下：
其實ioc/di對程式設計帶來的最大改變不是從**上，而是從思想上，發生了「主從換位」的變化。應用程式原本是老大，要獲取什麼資源都是主動出擊，但是在ioc/di思想中，應用程式就變成被動的了，被動的等待ioc/di容器來建立並注入它所需要的資源了。
這麼小小的乙個改變其實是程式設計思想的乙個大進步，這樣就有效的分離了物件和它所需要的外部資源，使得它們鬆散耦合，有利於功能復用，更重要的是使得程式的整個體系結構變得非常靈活。
還有乙個講的更細依賴注入和控制反轉的博文：
事務的隔離級別舉例 事務的隔離級別
乙個事務是乙個完整的業務邏輯單元，不能再分，要麼全部執行成功，要麼全部失敗。比如 a給b轉賬100元，a的銀行卡就會少100元，b的銀行卡就會多100元，整個過程要麼全部執行成功，要麼全部失敗。a 原子性。事務是最小的業務邏輯單元。b 一致性。乙個事務必須保證多條dml語句同時成功或失敗。c 隔離性...
事務的隔離級別舉例 JDBC 事務隔離級別
本文總結了 jdbc 事務隔離級別。事務隔離級別定義了在乙個事務中，哪些資料是對當前執行的語句 可見 的。在併發訪問資料庫時，事務隔離級別定義了多個事務之間對於同個目標資料來源訪問時的可交叉程度。可交叉程度可分為以下幾類。可交叉程度 dirty reads 髒讀 當乙個事務能看見另外乙個事務未提交的...
事務的隔離級別舉例 JDBC事務隔離級別
一組要麼同時執行成功，要麼同時執行失敗的sql語句。是資料庫操作的乙個執行單元。斷開與資料庫的連線 表示乙個事務內的所有操作是乙個整體，要麼全部成功，要麼全部失敗 表示乙個事務內有乙個操作失敗時，所有的更改過的資料都必須回滾到修改前狀態 事務檢視資料時資料所處的狀態，要麼是另一併發事務修改它之前的狀...