Windowsばかりがある環境では　Microsoftの.NETFRAMEWORK の開発環境は最強である、、恐ろしいほどの開発工数の削減が可能で、更新も簡単だ

今回は開発環境のうち問題になるポイントをば、、
トランザくショナルな処理を行いたい場合は幾つかの方法があるが、その中でも推薦されているのが以下のライブラリを使ったトランザクション処理だ
System.Transactions.TransactionScope

スコープというだけあり、その範囲内に記載されたデータベース処理を単一、複数サーバー問わずにアトミックに処理できる優れた仕組みであり、また記述方法もシンプルでモジュール化も行いやすい

Using(var tran = new System.Transaction.TransactionScope()){

//テーブルアダプタのセレクト処理（サーバ１）

//テーブルアダプタの更新処理（サーバ２）

//モジュールに分割された他のデータベース処理

// 上記結果を踏まえたテーブルアダプタの更新処理（サーバー１）
//コミット
tran.commit();
}

と、、とても使いやすいんだけど難点がある、それはプログラムの記述方法により『分散トランザクション』が発生した際にMS-DTCの設定がDBサーバーと各クライアントに必要になること、、

MS-DTCの設定であるが少なくともWindows2003までのActiveDirectoryが提供するグループポリシーでは自動設定が出来ないために、個別にクライアントへの設定が必要になってくる。

ファイヤーウォールでのmsdtc.exe プログラムの通信を許可することも必要

また、厳密な処理をするためかNetBiosでクライアントからDBサーバーのIPアドレス、またサーバーからは逆引きでクライアントのIPアドレスを特定できる必要があるが、ケースにより逆引きが正しく行えないなど、運用面ではトラブルが起きやすい。

話をもとに戻すとそもそも『分散トランザクション』とは複数のDBサーバーをまたぐ際に一貫した処理を維持するための機構であり、『２層コミット』とも呼ばれる仕組みで、オール or ナッシングを実現している。

大規模なシステムでない限り１台の DBサーバーとの間では必要ない仕組で、単純にプログラムの記述を簡潔に行いたい場合においては『要らぬ世話』なのである。

だがしかし、１台のDBサーバーとやり取りをするプログラムであってもコネクションが複数になると自動的に『分散トランザクション』へ昇格してしまうことが今回の問題。

Visualstudioで開発しているならば型付データセット、テーブルアダプターは開発工数を劇的に下げる素晴らしい仕組みだが、TransactionScopeとは完全に相性がいいわけではない。

Using(var tran = new System.Transaction.TransactionScope()){

//テーブルアダプタのセレクト処理（サーバ１）

//テーブルアダプタの更新処理（サーバ１）

//モジュールに分割された他のデータベース処理（サーバ１）

// 上記結果を踏まえたテーブルアダプタの更新処理（サーバー１）
//コミット
tran.commit();
}

この状態では『分散トランザクション』へ昇格する
原因はDBサーバーへのコネクションが複数張られるため

幾つかのサイトで　.NETFRAMEWORK2.0 SP1 とSQLServer2008である場合はこの制限がいくらか緩和されるようだが、あくまで１つのコネクションを共有する場合である。

緩和されているが、あまり劇的ではない。出来れば対象が一つのDBサーバーである場合スコープ内の処理方法問わず昇格しない様にしてほしいが、SQLServer2012のドキュメントをみてもこの辺りは改善されていないようだ。

またこの仕組、ローカル環境（プログラムとDBSQLServerが同一マシン）では一切昇格しないので、ネットワーク環境でテストして初めて直面する問題であり、自分としてはとても厄介だ。

この問題は、複数のコネクションが発生する場合に起きる、つまり単一コネクションを引き廻せば良いことになる。

これに対しての一つの解決策がコネクションをSingletonパターンで作成すること
これで”唯一のコネクション”を確保できMS-DTCへの昇格を防ぐことが出来る。

さて、実装していってみよう。