先講下spring的事務劃分的類別這個在面試邀請的電話中經常被問：
編程式事務管理使用TransactionTemplate或者直接使用底層的PlatformTransactionManager。對於編程式事務管理，spring推薦使用TransactionTemplate。
聲明式事務管理建立在AOP之上的。其本質是對方法前後進行攔截，然後在目標方法開始之前創建或者加入一個事務，在執行完目標方法之後根據執行情況提交或者回滾事務。聲明式事務最大的優點就是不需要通過編程的方式管理事務，這樣就不需要在業務邏輯代碼中摻雜事務管理的代碼，只需在配置文件中做相關的事務規則聲明(或通過基於@Transactional註解的方式)，便可以將事務規則應用到業務邏輯中。
顯然聲明式事務管理要優於編程式事務管理，這正是spring倡導的非侵入式的開發方式。聲明式事務管理使業務代碼不受污染，一個普通的POJO對象，只要加上註解就可以獲得完全的事務支持。和編程式事務相比，聲明式事務唯一不足地方是，後者的最細粒度只能作用到方法級別，無法做到像編程式事務那樣可以作用到代碼塊級別。但是即便有這樣的需求，也存在很多變通的方法，比如，可以將需要進行事務管理的代碼塊獨立爲方法等等。
聲明式事務管理也有兩種常用的方式，一種是基於tx和aop名字空間的xml配置文件，另一種就是基於@Transactional註解。顯然基於註解的方式更簡單易用，更清爽。
//上面那段copy於互聯網！
第一個問題就是什麼是事務：
事務（Transaction）是併發控制的基本單位。所謂的事務，它是一個操作序列（你可以把他理解成在併發環境下的有序操作，也就是線程安全的，但是在業務中也是存在的問題就是業務數據越安全，性能就越垃圾，所以在很多時候，在性能和數據安全的情況下做下取捨），這些 操作要麼都執行，要麼都不執行，它是一個不可分割的工作單位（可以把它理解成鏈條，少了一個就不完整了是吧）。所以，事務是數據庫 維護數據一致性的單位，在每個事務結束時，都能保持數據一致性。
第二個問題就是事務是什麼：
① Atomic（原子性）：事務中包含的操作被看做一個邏輯單元，這個邏輯單元中的操作要麼全部成功，要麼全部失敗（一個朋友經常講的一句話"不是生，就是死"講白了就是要麼全部是"死"，要麼全部是"生"，這裏的生死主要指得是數據在執行刪除啊修改啊這些操作的時候狀態）。
② Consistency（一致性）：事務完成時，數據必須處於一致狀態，數據的完整性約束沒有被破壞，事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣(這個我一直把他和原子性理解的差不多，唯一的不同就是，發現自己死到一半發現自己不想死，又想活過來，可以滾回來保持活着的狀態)。
③ Isolation（隔離性）：事務允許多個用戶對同一個數據進行併發訪問，而不破壞數據 的正確性和完整性。同時，並行事務的修改必須與其他並行事務的修改相互獨立。 (也就是講有多個同學，你們一起在幹讀寫數據的操作，但是每個同學的事務都是獨立的，不會互相影響，這個地方以後再做更加詳細的講解暫時沒有想到好的例子)
④ Durability（持久性）：事務結束後，事務處理的結果必須能夠得到固化。（男人是不是要持久，數據的持久化有哪些？自己想想）
下面講講事務的幾類問題：
髒讀：也就是讀入了沒有提交的數據。爲什麼會這樣呢？
下面舉個栗子：
看好下面的栗子圖：
看到上面的圖分爲三列：時間，事務a取款，事務b存款。
然後結合時間的操作順序來看這個栗子會出現上面問題：
問題出在a取款了100但是事務還沒有結束也就是它可以滾回去的，但是事務b直接就把那個數據狀態給查詢得到了形成了“髒讀”，其實就是一個事務沒有結束，另外一個事務就“讀”取得到數據了，然後前面那個事務又回滾就出現了髒讀。
不可重複讀：
事務a是不是執行了2次讀取數據的狀態
這是由於查詢時系統中其他事務修改的提交而引起的。比如事務T1讀取某一數據，事務T2讀取並修改了該數據，T1爲了對讀取值進行檢驗而再次讀取該數據，便得到了不同的結果。
幻讀：A事務讀取了B事務新增的數據，幻象讀和不可重複讀是兩個容易混淆 的概念，前者是指讀到了其它已經提交事務的新增數據，而後者是指讀到了已經提交事 務的更改數據（更改或刪除，你也可以理解成更改和刪除引起的不可重複讀就是幻讀哈哈）
還有幾個沒有寫明天寫完！