將不確(que)定變為確(que)定~transactionscope何時提升為分(fen)布式事務~大(da)結局
之前寫(xie)過三篇這個文(wen)章系列,都是圍繞一(yi)個主(zhu)題,那就(jiu)是.net何時將transactionscope提(ti)升為分布式(shi)事務,今天我借(jie)用ThreadStatic特性(xing),把這個知識點(dian)又證明了一(yi)下(xia)(xia),下(xia)(xia)面總結一(yi)下(xia)(xia):
transactionscope文章:
第二十六回 將不(bu)確定(ding)變為(wei)確定(ding)~transactionscope何時提升為(wei)分(fen)布式(shi)事務?
第二十七回 將不確(que)(que)定(ding)變為確(que)(que)定(ding)~transactionscope何時提(ti)升為分布式事務(wu)~續
第(di)二十八回 將不確(que)(que)定變為確(que)(que)定~transactionscope何時提升為分布(bu)式事(shi)務(wu)~再續(避免引起不必(bi)要的(de)MSDTC)
ThreadStatic特性文章:
基礎才是(shi)重中之重~ThreadStatic靜態字(zi)段在每(mei)個(ge)線程里(li)的唯一(yi)性
大總結:
數據上下文只有是一個,才有可能不會產生分布式事務
數(shu)據上下文(wen)是一個(ge),并且(qie)SubmitChange也是一個(ge),這時,才(cai)不會提升為分布式事務(MSDTC)
看一下圖,這(zhe)是一個ThreadStatic特性(xing)的DataContext的圖示,我已經禁用的MSDTC服務
而(er)(er)下(xia)(xia)面的圖(tu)是我(wo)使用普通的實例數(shu)據上(shang)下(xia)(xia)文,它將產(chan)生(sheng)多個數(shu)據上(shang)下(xia)(xia)文,從(cong)而(er)(er)將transactionscope提升為分布式事務(wu),所(suo)以,下(xia)(xia)面圖(tu)的異(yi)常也就被拋出來了,呵(he)呵(he)!
下面為方法(fa)調用:普通實例上下文
ThreadStatic特性的數據上下文
下(xia)面(mian)是(shi)事(shi)務(wu)的程序塊(kuai),它有多個操(cao)(cao)作(zuo),每個操(cao)(cao)作(zuo)都(dou)有自己(ji)的SubmitChanges()
而(er)它(ta)產生的SQL語句,則是使用了一個SQL連接池,性(xing)能方面(mian)已經是最優了!
下面是使用iunitofwork模塊下,解決程(cheng)序提升到(dao)MSDTC的實(shi)例代碼,供大家參考
IUnitOfWork unitOfWork = new EEE114Entities(); iUser_Info = new EEE114RepositoryBase<User_Info>(unitOfWork); iUser_Profile = new EEE114RepositoryBase<User_Profile>(unitOfWork); using (TransactionScope trans = new TransactionScope()) { unitOfWork.IsNotSubmit = true; iUser_Info.Insert(new User_Info { UserName = "test", Password = "", RegisterTime = DateTime.Now, RegisterIP = "", UserStatus = 0, ApproveStatus = "00000", Experience = 0, Money = 0, Integral = 0, }); iUser_Profile.Insert(new User_Profile { UserID = 98056, RealName = "iunitofwork占(zhan)占(zhan)測試MSDTC" }); unitOfWork.Save(); }