之前一些應用經常會出現請求超時而引起使用者體驗極度下降，我們每個應用都會做使用者體驗的優化。當然有很多其它原因，但是對於
post的兩階段提交引起的訪問超時也發生過好幾次，而且基本無解，只能修改實現方式，儘量減少傳輸的資料以便改用get方式。
有不少瀏覽器廠商對於post的提交採用兩階段傳送資料，特別是ie系統列的xmlhttprequest物件，所以在ie瀏覽器上用ajax提交post的資料，
是按兩個階段，第一步先傳送header資料，第二步再傳送body部分。如果我們用winshark抓包會看到兩連次結過程。
而對於firefox瀏覽器，則採用一次連線，這也是原來http協議的「本意」，http協議本身不儲存任何狀態資訊，一次請求一次應答。對於tcp事務而言，
通訊次數越多可靠性越低，在一次鏈結中傳輸完需要的訊息是最可靠的，但是卻有很多瀏覽器廠商不願意遵守這個原則，它們的理由也很搞笑：
假如網路環境不好，網路延遲、丟包的時候，服務端會等待(延遲時)，客戶端重發post的data資料到服務單，來確保本次請求的完整性。
這完全是乙個狗屁理由，header資料相對於body資料來說都是很小，如果一次傳輸中只收到header,body卻丟了，那麼這一次請求對於服務端來說，它只
有等待超時才會知道後面的body沒有了，這時它已經向客戶端傳輸了請求錯誤碼。客戶端根本就談不上重發body。當然如果瀏覽器廠商和web伺服器
是同一廠商，他們可以在收到header後等待body超時時傳送乙個重發指令給客戶端，但是目前沒有任何web服務端是這麼做的，而且，這也從根本上違反了
http協議的規範，因為對於超時鏈結，如果再等它重發資料，再超時，再重發？那使用者在web服務端定義的「超時」還能得到什麼保證？
還不如一次連同header加body傳送，如果資料報不完整，服務端返回鏈結超時使用者只需要重刷一次即可，而如果兩次提交，當收到header時，服務端的處理
程式首先要開闢記憶體hode住header資料再等待body,對於同步處理的話當前程序或執行緒不能服務其它請求，極大降低服務端效能。最後還是返回異常給客戶端，
對於非同步處理的話你根本不知道body什麼時候過來，如果客戶端只傳送header就下線了，服務端可能要hode這個資料n久。
今天上午風控專案中使用hessian呼叫又出現超時問題，經過分析hessian的post也是兩階段提交，無解，除非換協議。
對於ajax的使用，yahoo推薦用get代替post，所以如果資料量不是很大，堅決不要用post。
兩階段提交
1 二階段提交協議 一般分為協調器c和若干事務執行者si兩種角色 當執行某一事務t的所有站點si都通知c事務執行完成，c即啟動二階段提交協議。1.首先c向所有si發訊息 c先將訊息寫到本機日誌 si收到訊息後，根據本機t的執 況，如果成功返回，不成功返回。返回前都應把要返回的訊息寫到日誌裡 2.c收...
兩階段提交
在分布式系統中，事務往往包含有多個參與者的活動，單個參與者上的活動是能夠保證原子性的，而多個參與者之間原子性的保證則需要通過兩階段提交來實現，兩階段提交是分布式事務實現的關鍵。很明顯，兩階段提交保證了分布式事務的原子性，這些子事務要麼都做，要麼都不做。而資料庫的一致性是由資料庫的完整性約束實現的，永...
兩階段提交
翻譯自 不像在本地資料庫的事務，分布式資料庫涉及到在多個資料庫中改變資料，因此，分布式事務處理更加複雜，因為資料庫間必須協調保證整個事務的原子性，即要不全部成功，要不全部失敗。事務一旦提交，無法回滾 資料保證資料的完整性的方式是使用兩階段提交 xa transaction 第一階段稱為準備階段，事務...