System.Transactions 裡的 Timeouts 與 Azure 中的設定

在進行交易的過程中，主要有三個 Timeout 時間。而真正的可交易時間，是取下面三者的最小值。

Command.CommandTimeout

這個 timeout 是最基本的 Timeout 時間，預設為 30 秒。這個設定是執行sql指令的可執行時間。

TransactionScope 的Timeout

在執行交易時，TransactionScope 也有一個 Timeout 時間。這個時間是由 TransactionScope 的建構子中的參數來指定的。預設值是60秒，可由 TransactionManager.DefaultTimeout 取得設定值。

TransactionManager 的  MaximumTimeout

TransactionManager 裡頭也有一個 timeout。這個 timeout 時間是是全機的交易管理員的最大可交易的時間。在 .NET 2.0 預設可由子層的 config 或程式來覆寫。但在 .NET 4.0，就不能被子層來覆寫了，如果需要修改，則必須到 %windir%\Microsoft.NET\Framework\v4.0.30319\Config\machine.config (32 位元)，或 %windir%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config 中以管理員的權限進行修改。

<system.transactions>
    <machineSettings maxTimeout="02:00:00" />
</system.transactions>

Azure 中設定

微軟的 Windows Azure Cloud Service 環境中，當然我們可以使用遠端桌面的方式，連線到每個伺服器進行上述的修改。但是一旦重新掛載作業系統後，這些人工設定又全部跑掉必須重設，非常不人道。幸好部署時有 Start Task 的機制, 可以執行 cmd 的指令。cmd 指令如下

windir%\system32\inetsrv\appcmd set config /commit:MACHINE /clr:4 -section:machineSettings -maxTimeout:02:00:00

此指令必須寫成 .cmd 檔，放在 WebRole 或 WorkerRole 的 project 內，以 content/Always copy to Output Directory 的型式加入專案

  

接著，在Azure 專案的 ServiceDefinition.csdef 中加上 Startup Task 的指令

<Startup>
  <Task commandLine="timeout.cmd" executionContext="elevated" taskType="simple" />
</Startup>

如下圖

其中 executeContext=”elevated” 指的是必須以管理員的權限進行修改

結論

TransactionScope 的 Timeout 設定有點複雜，除了.NET 版本，32/64 版本，%windir%\system32\ 與 %windir%\SysWOW64\ 的不同外，現在又增加了雲端的設定。真是不太容易。

參考

1. http://stackoverflow.com/questions/1348191/default-transaction-timeout
2. https://github.com/Aaronontheweb/azure-webroleperformance-scripts
3. http://blogs.inkeysolutions.com/2012/01/managing-timeouts-while-using.html

jQuery 取得 checkbox 至少有一個選取

客戶的需求中，「當使用者至少要選取一筆資料才能進行下一個動作」。常見的 UI 設計，當然是使用 checkbox。

而我的 case，是資料有一萬多筆，此時整個網頁非常痴肥而難以接受。問題是，客戶就是要這樣的網頁，客戶拒絕分頁。

jQuery length

問題來了，此時我使用了如下的 jQuery 語法查詢是否有選取一個 checkbox

var isChecked = $('input[name=chk]:checked').length > 0;

相當然爾，網頁就硬生生當在那裡，動也不能動。效能不好

jQuery is

根據我「多年」「 .NET」的經驗，使用 length 等同於計算所有被勾選的項目，然後再計算出總筆數，這樣的效能當然不好啊。於是趕快找一找 jQuery document，很快的就發現了 jQuery is 非常符合我的需求。於是馬上改了程式

   1: var isChecked = $('input[name=chk]')is(':checked');

滿心期待效能飛快，但「更慢了」。怎麼會…

效能比較

找到一個測試，也證實了這樣的結果。怎麼會這樣…

另外，又找了一個 checkboxtests，這次加入了自己寫的 .each() 來測試是否會比較快？結論是：不會。

心得

到了 javascript 的世界，以前許多經驗值就必須大打折扣了。

將 Visual Studio 打包好的 package 佈署到 IIS 6

之前的許多經驗，都是把打包好的 package 佈署到 IIS 7 以上的版本。此中又依據權限，再分成管理員權限的佈署及非管理員權限的佈署方式。

這次，我被要求佈署到 IIS 6 上了。

IIS 6

我之前的態度，是一味地以「Windows Server 2003 大舊了，現在沒有人在用了」來推託一翻。雖然言之有理，但其是一大部份原因是：懶！
然而，債還是要還的。客戶出錢，我們做人家小的還是要出力，即使入不敷出。

IIS 6 與之後的 IIS 7有個根本上的不同，是IIS 7 對 metabase 的全面改版，並且 IIS 7 可支援非管理員來管理 IIS。在 Visual Studio 發行的結果，是對 Web Deploy 是再包裝過精簡後的工具，處理的對象是  IIS 7 的 metabase。對於 IIS 6，只能自行尋找文件。

如果直接使用 Visual Studio 所產出的 cmd 指令執行到 IIS 6，會出現如下的錯誤訊息。

使用 MSDeployAgentService

在同一個目錄中，可以找到 Visual Studio 為我們寫好的 readme 檔案，其實裡面已經寫的很清楚了，是可以使用這些工具部署到 IIS 6的。

The service URL can also be in the following format:
        http://<DestinationServer>/MSDeployAgentService 
    This format requires administrative rights on the destination server, and it requires that Web Deploy Remote Service (MsDepSvc) be installed on the destination server. IIS 7 does not have to be installed on the destination server.

也就是說， 我們必須使用 http://serverName/MSDeployAgentService 使用管理員權限來進行部署。

改一下指令，如下

package.cmd /T /M:http://localhost/MSDeploymentService

結果不如人願，非常類似的錯誤訊息還是打擊了我一下。

解法

注意到了問題了嗎？另一個重點在於 Metabase 路徑，新舊版本不一樣。所以，我偷偷修改了SetParameters.xml，由原來的

<setParameter name="IIS Web Application Name" value="Default Web Site/myApp" />

改成

<setParameter name="IIS Web Application Name" value="/lm/w3svc/1/ROOT/myApp" />

再執行相同的指令

package.cmd /T /M:http://localhost/MSDeploymentService

就完成了我的需求了。

其實，如果是在本機的話，指定機器的 /M 指令也不用加了。只需要

package.cmd /T 即可

進階

由於使用了 MSDeploymentService，就必須使用管理員的權限。既然是管理員權限，在別台機器(只需要安裝 Web Deploy Tool)當然也可以下指令，不必遠端桌面登入到該伺服器。

package.cmd /Y /M:http://serverIpOrHostName/msdeployagentService /U:administrator /P:Password

PS: 對部署來說，這個權限要求實在大到不行，對於無限上綱的資訊安全管理說，就是很好發揮的題材。誰叫你還要用 Windows Server 2003 呢？