今天在回顧之前學的事務時，有一個知識點完全遺忘了。那就是事務的傳播性。

舉個例子：

上淘寶買東西，我買本 【Spring 揭秘】，就在下單的時候，我支付寶錢不夠，支付失敗，這個支付的過程肯定帶事務的，支付失敗就代表之前的操作都會回滾，數據不進入數據庫【其實是會進的，在未付款訂單裏面，等待付款】，我要講的是，我瀏覽商品的這個記錄也應該在這個支付事務裏面，事務被回滾了，那這個瀏覽商品的記錄在不在數據庫呢？結果是肯定的，肯定會記錄在數據庫，要不然接下來的幾天，淘寶怎麽給你推薦你想買的寶貝呢？

這就涉及到了事務的傳遞特性，事務中嵌套事務，外層事務和內層事務的關系。

【其實我上面的例子說不過去，我的理解肯定是有問題的。不管你買不買，只要你瀏覽了，淘寶就會給你推薦類似的寶貝，不管你下沒下單。但我暫時只能想到這個不合適的例子了】

下面這段話摘錄自【深入淺出事務之傳播屬性】

在用 SSH 開發項目的時候，一般都是將事務設置在 Service 層 那麽當調用 Service 層的一個方法的時候它能夠保證我們的這個方法中執行的所有的對數據庫的更新操作保持在一個事務中，在事務層裏面調用的這些方法要麽全部成功，要麽全部失敗。那麽事務的傳播特性也是從這裏說起的。
如果你在你的 Service 層的這個方法中，除了調用了 Dao 層的方法之外，還調用了本類的其他的 Service 方法，那麽在調用其他的 Service 方法的時候，這個事務是怎麽規定的呢，我必須保證我在我方法裏掉用的這個方法與我本身的方法處在同一個事務中，否則如果保證事物的一致性。事務的傳播特性就是解決這個問題的，“事務是會傳播的”在 Spring 中有針對傳播特性的多種配置我們大多數情況下只用其中的一種: PROPGATION_REQUIRED：這個配置項的意思是說當我調用 service 層的方法的時候開啟一個事務 ( 具體調用那一層的方法開始創建事務，要看你的 aop 的配置 ) ,那麽在調用這個 service 層裏面的其他的方法的時候,如果當前方法產生了事務就用當前方法產生的事務，否則就創建一個新的事務。這個工作使由 Spring 來幫助我們完成的。

以前沒有Spring幫助我們完成事務的時候我們必須自己手動的控制事務，例如當我們項目中僅僅使用hibernate，而沒有集成進spring的時候，我們在一個service層中調用其他的業務邏輯方法，為了保證事物必須也要把當前的hibernate session傳遞到下一個方法中，或者采用ThreadLocal的方法，將session傳遞給下一個方法，其實都是一個目的。現在這個工作由spring來幫助我們完成，就可以讓我們更加的專註於我們的業務邏輯。而不用去關心事務的問題。

被我忽略的事務的傳播性