MS ８月 セキュリティーパッチ 不具合
1 Mins read
ステートサーバ機能
1 Mins read
ネタとしては古いが（苦笑）管理人の覚書としてIIS6のセッション変数機能がパワーアップされているので記述しておく。従来のWeb機能ではセッション内容を他に簡単に移動させておけなかったので、IISが止まるとセッション内容も一緒に死んじゃってましたが、別プロセス（別空間）に保存できるようになったのでIISの再起動をしても、なんと！セッション情報が消えないのである！！！エッヘン（笑）なおかつこの機能を使うと別のマシン上にセッション情報を置けるので負荷分散でWebサーバーを複数台動かす時にも役立ちます。ちなみにTomcatも最近この機能が出来るようになったみたい。管理人としてはこの機能をパワーアップしてセッション内容をXMLファイルとしても保存、読込みできるメソッドを追加してほしいと思う今日この頃です。ん？なんでファイルか？だって！それはSession変数の場合タイムアウトを気にしないといけないのに対してファイルは気にしないで情報を取っておけるメリットがあるのですね。SQLServerには保存できるらしい・・・
通常、セッション情報はASP.NETアプリケーションを実行するワーカー・プロセス（IIS本体ではなく、実際にアプリケーションを処理するプロセス）内部に保存されているが、より高レベルなサービスを提供するために、ステートサーバと呼ばれる、プロセス外にセッション情報を保存する手段が提供されている。
ステートサーバを利用するメリットは、信頼性の向上にある。ステートサーバはIISから独立したプロセスとして実行されるため、ワーカー・プロセスが誤動作したり、IISを再起動したりしても、ステートサーバに保存されたセッション情報が失われることはない。もちろん、その瞬間にアプリケーションが起動されていたセッションは正しいレスポンスを返すことはできないだろうが、ユーザーからのポストバックを待っていたセッションは、IISさえ正常に戻れば、そのまま何食わぬ顔で処理を継続できる。
また、IISとステートサーバは、ネットワーク接続さえされていれば、同一マシン上に存在していなくても構わない。従って、Webファーム（クラスタ化されたWebサーバ群）に対して、独立したステートサーバを1台用意する構成を取れば、1台のWebサーバに障害が発生しても、残りのWebサーバがセッションを継続できる（ステートサーバがウイークポイントとなってしまうが）。
パフォーマンスでは通常のインプロセス・モードに分があるが、信頼性を優先させるならば、ステートサーバ・モードの利用を検討するとよいだろう。
ステートサーバ・モードを利用するにあたって必要な作業は、ステートサーバを起動し、以下に示すweb.configファイルを用意することだけだ。アプリケーション・コードに修正は必要ない。web.configファイルでは、sessionState要素のmode属性に”StateServer”を、stateConnectionString属性に「tcpip=＜ステートサーバ・マシンのIPアドレス＞:42424」を設定すればよい。
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424" />
</system.web>
</configuration>
ステートサーバは「ASP.NET State Service」の名前でサービスとして登録されているので、サービス・マネージャで起動する。
なおここでは割愛するが、セッションの情報はSQL Serverによりデータベースで管理することも可能だ。
MSセキュリティーパッチ
1 Mins read
MySQLのODBC接続について
1 Mins read
日本語環境(cp932など)でMySQLにODBC接続をする際にはクライアント側キャラクタセット、サーバー側キャラクタセット、クライアントに結果を返す為のキャラクタセットが重要になってくる、フォ～っ！「SET CHARACTER SET cp932」をつけるようにするとたい（笑）
以下抜粋
各接続には接続キャラクタセットと接続照合順序があり、いずれもヌルにすることはできません。実際には 2 つの接続キャラクタセットが存在するため、両者の区別が必要な場合は “接続/リテラル” および “接続/結果” の呼称を使い分けています。
“接続” とは、サーバへの接続時に作成されるものです。クライアントは接続を介し、SQL ステートメント（クエリなど）をサーバに送信します。サーバでは接続を介し、応答（結果セットなど）をクライアントに返します。これによって、次のような疑問が生じます。(a) クライアントから送信される際にどのキャラクタセットでクエリが送られるのか。(b) サーバではクエリを受信した後にどのキャラクタセットに変換するのか。(c) サーバでは結果セットまたはエラーメッセージをクライアントに返送する前にどのキャラクタセットに変換するのか。これらは細かく調整することができますが、デフォルトを適用することもできます。デフォルトを適用する場合、このセクションをとばしてかまいません。
接続キャラクタセットに影響するステートメントが 2 つ存在します。
SET NAMES character_set_name
SET CHARACTER SET character_set_nameSET NAMES は、クライアントから送信される SQL ステートメントのキャラクタセットを示します。たとえば、SET NAMES cp1251 は 「このクライアントからの入力メッセージは今後、キャラクタセット cp1251 になります」 とサーバに通知します。サーバでは適宜、独自のキャラクタセットへと自由に変換することができます。
SET CHARACTER SET は、クライアントから送信される SQL ステートメントのキャラクタセットと、サーバからクライアントに返される結果セットのキャラクタセットを示します。そのため SET CHARACTER SET は、SET NAMES を含んでいるほか、たとえば SELECT ステートメントを使用する際にどのキャラクタセットでカラムに値が保持されるかを示します。
例:column1 が CHAR(5) CHARACTER SET latin2 として定義されているとします。SET CHARACTER SET が指定されていない場合、SELECT column1 FROM t に対しサーバは、キャラクタセット latin2 を使用して column1 の値をすべて返します。一方、SET CHARACTER SET latin1 が指定されている場合、サーバは送信前に latin2 の値を latin1 に変換します。そのような変換は低速であり、損失につながることもあります。
SET NAMES または SET CHARACTER SET の実行時には、“接続照合順序” も変更していることになります。ただし、接続照合順序は整合性の維持のみを目的として存在しています。通常、その値は重要ではありません。
mysql クライアントでは、起動するたびに SET NAMES を実行する必要はありません。–default-character-set-name オプション設定を mysql のコマンドラインか、オプションファイルに追加することができます。 たとえば、以下のオプション設定ファイルの設定では、mysql を実行するたびに接続キャラクタセットが指定されます。
[mysql]
default-character-set-name=character_set_name
MySQL Administratorの日本語化について
1 Mins read
MySQLのGUIツール「Administrator」を使ってみた。CUIゴリゴリも良いけど、低レベルな私にとってはGUIも捨てがたい機能なのよね。バックアップも一発回答でまことにグゥ～！な一品に仕上がっている！
後は日本語化に期待なんだけど、まだ有志の皆さんが登場していません。「mysqlx_translations_administrator.xml」ファイルなどをいじればいけそうなんだけど…そもそもスウェーデン製のアプリを日本語にって…スウェーデン人もそんなこと考えないよね（汗）ただでさえSift_JISとcp932とのすみ分けで「なんだ日本語は（怒）」って思っているだろうから（苦笑）
ちなみに同じ理由でQuery Browserも日本語化して！他力本願？