天天躁日日躁狠狠躁AV麻豆-天天躁人人躁人人躁狂躁-天天澡夜夜澡人人澡-天天影视香色欲综合网-国产成人女人在线视频观看-国产成人女人视频在线观看

WCF的問題和Using語句塊

  WCF客戶端不能用在Using語句塊中,因為它可能會拋出不可預知的異常。即使你捕獲了異常,仍有可能一直保持連接。讓我們來看看形成這一問題的歷史原因,并提出幾個補救措施。

  在.NET中,資源管理的基礎就是IDisposable和Using語句塊。除了CLR對象,.NET中一切對象均使用這些工具進行管理。因此,我們需要知道為何微軟對于WCF框架的資源管理如此一籌莫展。

  WCF客戶端的首要問題是Close/Dispose方法會拋出異常。這與框架設計指南以及IDisposable規約背道而馳,從而導致Dispose方法可以在Finally語句塊中被不安全的調用。

  更糟糕的是,只要不調用Abort,Close/Dispose方法就會一直保持連接。太多的連接打開就會帶來性能的問題,應用程序也會變得不夠穩定。

  在新聞組中,有關此問題的討論可以追溯到2006年,Brian McNamara介紹了這一設計缺陷的幕后故事

ICommunicationObject(它是 ServiceHost,ClientBase,IChannel,IChannelFactory與IChannelListener最終繼承的對象) 總是具有關閉對象的兩個方法:(a)Close,(b)Abort。按照字面的理解,如果希望主動關閉對象,則調用Close;若要強制關閉則調用 Abort。

因此,Close()方法會接收一個Timeout參數,并包括一個異步版本(因為它可能阻塞線程),而且Close()還會拋出異常。Close拋出的異常為CommunicationException(CommunicationObjectFaultedException是其子類)與TimeoutException。

相反,Abort()并不會阻塞線程(也不會拋出任何異常),因此沒有Timeout值,也并不包含異步版本。

這兩個概念從最初的Indigo一直沿用至今[譯注:所謂至今是指Brian發表帖子的時間2006年10月25日]。就目前而言一切正常。

最初的定義為ICommunicationObject : IDisposalbe。作為一個標記接口,我們認為它可以用于通知用戶在可能的時候即刻釋放對象。然而問題卻接踵而來。

從Beta 1版本開始,我們修改了Dispose(),讓其等同于Abort()方法。一部分原因是Dispose()應該完成最起碼的必要的對象清理工作。在Beta 1中,這可能算得上是我們的頭號麻煩了。用戶可以將它們的通道(channel)對象放在using()語句塊中,緩存中任何等待被取出的消息都可能會丟失。事務無法提交,會話可能得到告知收到(ACKed)的消息等。

鑒于用戶的反饋,在Beta 2中我們又修改了實現,讓Dispose()近似等于Close()。我們知道,異常的拋出是問題之所在(部分原因在這篇帖子中已經說明),因此我們試圖 讓Dispose變得更加“聰明”。那就是說,如果當前并非Opened狀態,就會在內部調用Abort()。這仍然存在一系列問題,最主要的是你無法從可靠性角度推斷系統。Dispose仍然會拋出異常,但并非總是會通知你某些事情發生錯誤。最終,我們決定將IDisposable從 ICommunicationObject中移走。經過幾番爭辯,IDisposable在ServiceHost和ClientBase中被保留了下 來,因為從理論上講,對于多數用戶而言Dispose拋出異常仍然是可以接受的,他們更偏向于使用using()的便利性,具有該標記接口就可以更及時地 清除對象。你可能主張(我們的一部分開發人員抱有同樣的態度):應該將它從這兩個類中移走,然而好也罷歹也罷,我們終究作出了選擇。對于這個問題,你永遠 都不可能達成一致,因此我們在SDK樣例中給出了最佳實踐,那就是遵循try{Close}/catch{Abort}范式。


  補救措施

  Steve Smith提出了CloseConnection擴展方法[譯注:原文并沒有給出CloseConnection擴展方法的帖子,你可以訪問IDisposable與WCF]。在Finally語句塊中可以調用該方法,而不是調用Close,它封裝了Close/Abort邏輯。

  新聞組的發帖人bog1978建議使用C# lambda以支持創建類似Using的結構。方法接收一個新的客戶端對象,以及一個匿名方法,該方法持有的代碼與正常使用using語句塊包含的代碼完全相同。

  最后,還有一個補救措施是Erwyn Van Der Meer定義的WCF服務代理輔助類。用戶可以創建它,而不是通常的代理類,它可以糾正在關閉連接時出現的問題。一旦創建,它就會自動構建實際的代理,然后通過只讀屬性暴露它。

  查看英文原文:The Problems with WCF and the Using Block

NET技術WCF的問題和Using語句塊,轉載需保留來源!

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播更多信息之目的,如作者信息標記有誤,請第一時間聯系我們修改或刪除,多謝。

主站蜘蛛池模板: 国产午夜不卡 | 久久这里只有是精品23 | 色视频色露露永久免费观看 | 一边捏奶头一边啪高潮会怎么样 | 午夜福利合集1000在线 | 日韩一区二区三区视频在线观看 | 人人啪日日观看在线 | WWW夜片内射视频在观看视频 | 99精品国产福利在线观看 | 久久国产av偷拍在线 | 精品人妻伦九区久久AAA片69 | 5278欧美一区二区三区 | 草莓视频在线看免费高清观看 | 驯服有夫之妇HD中字日本 | 蜜芽亚洲欧美一区二区电影 | 亚洲精品在线看 | 18未满不能进的福利社 | 麻婆豆腐传媒视频免费 | 精品无人区一区二区三区 | 欧美乱妇日本无乱码特黄大片 | 天天久久狠狠色综合 | 精品无人区一区二区三区 | 国产日韩欧美综合久久 | 欧美极品尿交 | 1000部做羞羞事禁片免费视频网站 | 精品动漫国产亚洲AV在线观看 | 麻豆乱码一卡二卡三卡视频 | 国产人妻人伦精品98 | 色综合欧美色综合七久久 | 久久影院毛片一区二区 | 日本最新免费区中文 | 亚洲国产精品一区二区三区在线观看 | 极品少妇高潮啪啪AV无码吴梦梦 | 欧美精品专区免费观看 | 伊人久久综合网站 | 国产 有码 无码 电影 | 日本久久精品免视看国产成人 | 操他射他影院 | 99久久国产露脸精品竹菊传煤 | 久久热免费视频 | 毛片免费在线播放 |