回到目錄

你是否真正了解TransactionScope？

相關文章

將不確定變?yōu)榇_定~transactionscope何時提升為分布式事務

將不確定變?yōu)榇_定~transactionscope何時提升為分布式事務~續(xù)      

將不確定變?yōu)榇_定~transactionscope何時提升為分布式事務~再續(xù)（避免引起不必要的ＭＳＤＴＣ）

一 了解事務選項，用它來控制嵌套事務

    public enum TransactionScopeOption
    {
        //如果存在環(huán)境事務（我認為應該叫嵌套事務，氛圍事務，ambient transaction），那么就加入其中，
        如果不存在就創(chuàng)建新事務。如果加入事務那么只有在環(huán)境事務提交后才算提交。
        Required = 0,
        //這個事務范圍將創(chuàng)建自己的事務,不會加入到當前外部事務中
        RequiresNew=1,
        // 如果處于當前活動事務范圍內，那么這個事務范圍既不會加入氛圍事務 (ambient transaction)，也不會創(chuàng)建自己的事務。
        當部分代碼需要留在事務外部時，可以使用該選項。
        Suppress = 2,
    }

二 何時會提升為分布式事務（何時發(fā)起MSDTC請求）

當你的ＷＥＢ服務器與數(shù)據(jù)庫服務器在同臺電腦上，對同一個庫進行操作時，它不會提升為分布式事務

當你的ＷＥＢ服務器與數(shù)據(jù)庫服務器在同臺電腦上，對于同一個庫，建立多個數(shù)據(jù)上下文時，它不會提升為分布式事務

當你的ＷＥＢ服務器與數(shù)據(jù)庫服務器在同臺電腦上，當你操作兩個庫的表，這時才會提升為分布式事

當你的ＷＥＢ服務器與數(shù)據(jù)庫服務器不在同臺電腦上，如果建立多于一個Connection連接，將會發(fā)起MSDTC

三 反映到linq to sql中，對于一個數(shù)據(jù)上下文，由于我們操作不當，也會產(chǎn)生多個Connection連接

這個方法本身沒有問題，做一件事件，而且職責很明確，當完成事情后，通過base.SubmitChange()方法提交到數(shù)據(jù)庫，這時，建立了connection，發(fā)送了sql語句，完成了這個通訊。

但有時，這種DAL層的動作需要被BLL層的業(yè)務進行組合，BLL層可以在一個事務范圍內調用多個類似的DAL方法，這時它們會把這種方法當成是分別獨立的工作單元，這是我們不希望看到的，因為在我們理解中，一個BLL業(yè)務應該是一個工作單元才對，返回到代碼中應該是，多個DAL層的方法被解釋為SQL語句后，提交一次就OK，所以，上面的代碼在進行組合后，可能會產(chǎn)生一些壞味道！

解決方法：

向BLL層開放數(shù)據(jù)上下文的SubmitChanges()方法及是否提交的屬性IsSubmitChange，在BLL層統(tǒng)一做提交，而對于DAL層的獨立的方法，在進行submitChanges()時，需要進行判斷IsSubmitChange是否為true,如果是，然后再提交,當然這個IsSubmitChange默認為true,即每次調用單獨的方法都會完成這個提交，這是正常的，也符合操作的完整性，

而在BLL進行組合方法時，先將必IsSubmitChange設為false，這時，DAL的方法將不會被提交，等待BLL的Submitchange()。

核心代碼：

提交屬性IsSubmitChange屬性默認為true

而對于BLL層，我們公開一個統(tǒng)一的操作對象，它會覆蓋掉基類的SubmitChanges方法，它的方法修飾符為public,對BLL層公開。

 BLL層的基類BLLBase，可以通過架造方法為IsSutmitChange屬性賦值

OK，到這里，我們的BLL無論是調用BLL其它業(yè)務組合，還是調用DAL層方法組合，都可以控制代碼何時去提交到數(shù)據(jù)庫了，對于一個業(yè)務對象，就應該是一個工作單元，呵呵。

回到目錄