如果是如此MTS本身即Connection pooling的功能, 而ADO有支持此項功能;
雖然在程式中是不斷建立新的Connection,但其實這些Connection是由MTS的
Connection pool中取出, 並不會一直不斷的連接及Disconnect;
而且真正使用
的connection數量, 也會比客戶端數要來的少;
但就我個人應用 MTS (COM+), 到目前覺得有一個很大的缺點:
在同一個Activity下, 不同 COM 之間所使用 Connection 都是不一樣的,
可以這樣說明:
1. 客戶端創建 A, 並呼叫 A1方法
2. 在A1方法中取得Connection, 對數據庫存取
3. 在A1方法中建立B, 並呼叫B1方法
4. 在B1方法中取得Connection, 對數據庫存取
在這樣一連串動作(同一個Activity中), 2, 4所使用Connection並不相同, 此時最後的
Transaction要透過另一個服務 DTC (Distributed Transaction Coordinator)來完成
在兩層式的架構中, 這樣一個動作, 只要同一個Connection, 就可以做完了, 但在三
層中, 卻隨著呼叫COM的次數, 所使用Connection數量就會一直增加, 也會導致效率的下
降;
當然要解決以上問題, 也可在規劃COM的接口, 多個參數將connection傳入, 不過這
樣呼叫起來, 總覺得怪怪的;
另外MTS (COM+), 還有另兩個問題
1. 同一時間下, 最多只允許16個Transaction Context存在, 也就是說, 在同時間下,
最多只允許16台客戶機呼叫 MTS(COM+) 的COM方法
2. Connection pool及DTC的設計, 不知道ADO以外的數據庫存取工具的相容性高不高?
目前我Try最多的還是ADO, 除了16個Transaction Context的限制之外, 其它的運用
到是沒有發現什麼問題;
但其它如 BDE、DBExpress, 可就不知道了