恥を記録する記事。

Visual Studioに限らず、多くのプログラム環境でSQLデータベースに接続するときは、

1. まずデータベースサーバーとの接続を確立し、そのハンドルを記録しておく
2. そのハンドルを使ってSQLをサーバーに投げ、データを操作する

となると思います。サーバーとの接続およびハンドルの管理を受け持つのが、COM(Visual Studio 6)ではADODB.Connectionクラスであり、.NET(Visual Studio .NET)ではSystem.Data.SqlClient.SqlConnectionクラスになります。

COM/PHP/Perlを使う限りでは、プログラムの最初に接続を確立し、特別に理由がない限りはプログラム終了までそのときのハンドルを使いまわすのが常でした。理由はサーバーへの接続と言う処理はサーバー・クライアント共に比較的重い処理でして、そう何度もやるべきものじゃないからです。

ところが.NETでは逆で同じ接続を長時間使うべきではなく、ひとまとまりの処理が終わったらさっさと接続を切ると言うのが正しい作法とのこと。接続プールという仕組みがあるため、何度も接続と切断を繰り返してもCOMの時のような負担はないらしい。

実際プログラム開始時に作製したSqlConnectionインスタンスを使いまわしていたら、知らない間に接続が切れてしまって、

• SqlClient.InitializeLifetimeService().InitialLeaseTime = TimeSpan.Zero → 無視される
• SqlClientのInitializeLifetimeServiceをオーバーロード → SqlClientは継承不可

と二日間散々悩み、下の参考文書を読んで椅子から転げ落ちそうになったやつがいるようです。お気をつけください。

[参考]毎回SqlConnectionのインスタンスを作成＆接続することに関して (Insider.NET)

フィリピンから帰国してから１週間、明日またシリコンバレーに出発w

さてシリコンバレー出張ではあまり困らないのですが、フィリピンなどアジアの出張先でたびたび困るのがLAN接続。コネクタがない、あっても使われている、空いていてもなぜか機能しない(フィリピンではこれが半分以上、罠だな -_-)など、ネットが欲しいときに使えないことが多々。

無線LAN化が進みつつあるのですが、どうも有線に比べて信頼性が低く、大きいファイルのダウンロードや日本のサーバにssh接続しているときに切れちゃってやり直しってことも。

やっぱり有線だとなると他のPCに繋がっているLANケーブルをハブで分けることになるのですが、現地会社の人にLANハブを頼んでも手に入らないことも多い。日本で買って持っていくと本体は小さくても実はACアダプタ込みでかさばるし、海外の240V電圧で動くACアダプタが付属しているのも稀。LANコネクタと電源コンセントが離れている場合も少なくない。

USBから給電できるハブならいざという時に便利かなと思ったのですが、探してみるとなかなか見つからない。1年以内に登場しそうなUSB3.0はより大きな電力が供給できるようですが、現在のUSB1.1/2.0で規定されている給電は電圧5V最大電流500mA、つまり2.5W。マシンによってはより多く給電できるようになっているものもあるようですが、あくまで規格外。

一方よく売られている5ポートハブの消費電力は、通常で3.0～3.5W。通常なわけで、瞬間的にはこれより多く必要な場合がないとはいえない。つまりUSBでは電力不足なんですね。

という前置きを経まして、USBから給電可能な数少ないハブ、IO DATA ETX2-SH5S を購入しました。「最大」消費電流480mA、ACアダプタの他にUSB給電用ケーブル付属。そして8cm×7cm×1.4cmの小型で50gの軽量と、まさに持ち歩くためのハブ。スピードが遅いとかあるのかもしれませんが、緊急的な使用には問題ないでしょう。これ持って行ってきます～

出張続きでなかなか試す機会がありませんでしたが、入れてみました。元々Vistaが十分動くCore2Duo 1.8GHz、2GB RAM、GeForce 8600M GTですが結構きびきび動く感じはあります。これが64ビットのせいなのか(2009/6/5追記)、Windows7の性能なのか、グラフィックドライバのおかげなのか、インストールしたてだからか現時点分かりませんが、もう少し使っていけば見えてくるでしょう。

64bit版は以前から興味あったのですが、手持ちに64bit CPUがなかった(延々とAthlonXPやPentiumM使ってたからw)、Core2 Duoのノート買ったら32bit版Vistaしか選択できなかった、無理に64bit版買ってまで試すほどでもなかったなどあって、なかなか機会がありませんでした。

ところがWindows7が発売されるまでに64bit環境を体験しておく必要が出てきました。その理由が意外なところで、実家。両親はそれこそ画面サイズ以外はネットブックでも十分なライトユーザーですが、未だにWindows 2000使ってまして私が変えなければ今後もそうでしょう。

とは言うものの私の知らない間にカメラやプリンタを買って来てソフトウェアのインストールはしているらしく、先日もなんか動きがおかしいと言うので帰った際に見てみたら対応がWindows XP以降のソフトウェア。これを説明してWindows 2000対応を確認するように両親に求めるのは無理と言うもので、Windows7に換えてしまおうと言うのが結論。換えたら5年は使い続ける→その間に64bitが主流になるのはほぼ確実→だったら今から64bit→私が身を以って64bitが使えるか事前調査という流れになりました。

こういう目的なのでインストールして動いたよ程度ではだめで、常用環境として使っていかないといけない。ゲームが動くかが一番気になる点なのですが、今のところ少々難(ドライバのデジタル署名とか)あるものの順調。う～ん、Vistaを使わなくなってしまいそうだな。

[2009/6/3 追記] Windows7が軽く感じる可能性としてウィルス対策ソフトの有無も挙げられます。後日VistaのAntiVirus切ってみますかね・・・

[2009/6/5 追記] Intel Core2 Processorは32bitに最適な設計にしてあり64bitはむしろ消費電力・パフォーマンスともに悪化する傾向にあるようなので、64bitだから速くなったという線は薄そうですが。

空港で床に落としました・・・・

思えば購入 から1年半、デスクトップを隠居に追い込み個人用ゲームPCとして国内・海外に大活躍でした。あとはもうちょっと軽くて、ポインティングデバイスがトラックポイントだったら文句なしだったのですが。いままで、ありがとう！

・・・・まだ使えるってw 欠けた部分を瞬間接着剤でくっつけておしまい。落下時はクッション地のバッグに入れてあったのに。ThinkPadなら裸でこの程度の落下でも表面の傷くらいで終わりなこと多いんだけどなぁ。

Tclにはイベントドリブンで処理を行う方法が用意されています。

proc record1 { } {
  global s
  gets $s data
  set f [open "c:/temp/record.txt" a+]
  puts $f $data
  close $f
}

set s [socket 127.0.0.1 8097]
fconfigure $s -blocking 0 -buffering line -translation auto
fileevent $s readable record1
vwait a

こういうコードを書くと、サーバ(この場合localhost)のポート8097に接続しサーバから送られてくるデータをファイルに保存していきます。fileeventがTclのイベント処理に登録するコマンドで、読み取り可能なデータが入ってくると関数record1が呼び出されるようにしています。vwaitが変数aに値がセットされるまでイベント処理を続けるコマンドですが、このコードには変数aをセットするところがありませんので延々とイベント処理が続きます。

一方Tcl環境をC#等Managedな環境と一緒に使う場合Tcl/CSharp やEagle といった間を取り持つ層を用いますが、Tcl/CSharpを用いて以下のことをやるとします。

1. C#側でソケット接続を受け付けるようにする
2. C#側で同じプロセスの別スレッドからTcl interpreterを作成する
3. 作成したTcl interpreterから先ほどのC#で作ったソケットサーバに接続する
4. Tcl側で上のようなfileeventを使う方法で、C#側とソケット通信する

なぜこんな変なことをするのかは聞かないで(^^;) 実際には通信を開始する前にTcl interpreterにはコマンド追加などさまざまな操作をしており、それが今回の問題を引き起こしているかもしれないのですが、その内容はここには書けませんw

ここで問題が発生しまして、

• Tcl側でデータを一切受信しない。上の例で言えばrecord1が呼ばれません。
• ソケット接続は行われるのでTcl側が全く動いていないわけではない。
• telnetや即席のソケット通信プログラムを使用する限りC#側のソケットサーバーはデータを送信しているので、C#側に問題はない模様。
• ソケット通信TclスクリプトをC#とは別プロセス(別途起動したtclshやwish)から立ち上げるとちゃんと通信する。

これを解決するためTclスクリプト側に以下を追加しました。

proc EventKeepAlive { } {
  after 100 EventKeepAlive
}
after 100 EventKeepAlive
(ここまでvwaitより前に)

100msecごとにEventKeepAlive関数が延々と呼ばれると言うだけで全く仕事をしないこの部分、これを追加するとC#と同じプロセスで作られたTclインタープリタでもちゃんと通信するようになりました。

理由、分かりません。こうやってTclのイベントを絶えず使っておかないと止まってしまうようです。ここ 書いてあるスレッドが止まると言うことと原因は同じなのかなぁ。

この解決を見つけるまで.NET Frameworkのマルチスレッド処理がおかしいのではないかとかいろいろ大変でした。ただあまりに特殊なことをやっているためここに書いても同じ状況にぶつかる人がいるのか疑問ですがｗ