« 衝撃! informixでも件数制限出来た | トップページ | うるさいダイアログ »

2005.12.23

変数設計の難しさ

ウェブ系システムで(私は断じてウェブ系システムは専門ではない)最近あった実例だが、トランザクション系の仕組みでありながらReloadやhistory.backを許容するという野心的な作りであった。(というとおおげさ?)
ま、それ自体はいいんだが、ある更新系の処理を実行する画面で、別の画面へ遷移できる設計であった。
主処理を行ってから「戻る」で戻り再度主処理を実行すると、同じトランザクションを2回流すことになる。
発注系の処理なんでコレ自体も問題といえば問題なのだが、設計者の根本的な考えとしてこれは"仕様"とのことなので、まあよい。
問題は副処理を行ってから通常の遷移ではなく元の画面へ戻り、主処理を実行した場合。普通に考えれば単純に主処理が正しく実行されるはずだったのだが、この副処理から戻ったときのみ処理結果が異常になるということにでくわした。

このアプリケーションは最終的なDB処理はすべてストアドプロシージャで行われるのだが、必要な引数はすべてプレゼンテーション層からポストされる。
にもかかわらず副処理から戻った場合に異常な値を返すのはなぜなのか?
ユーザーさんから相談を受けて解析開始。
システムの構成は典型的な3階層システム。ビジネスロジックはDB層で構築されている。
手元にあるのはプレゼンテーション層のテスト環境とストアドプロシージャの定義書という状況であり、まあダメもとでスタート。

結論からいえばJavaScriptの変数設計が問題で、同じ変数を複数の意味をもたせていたのだった。
主処理も副処理もストアドプロシージャに引数を渡すのだが、トランザクションの状態を表現する変数が「プロセスステータス」という意味のものであったため、共通化して使用されていた。ところが、引数の値の意味が主処理と副処理では異なった。このため副処理から戻ったときにはすでに副処理用に変数がセットされた状態のまま主処理に遷移したために、主処理上で異常な処理を実行することとなったようだ。

対策として主処理に引き渡すときのJavaScriptにこの変数の再初期化処理を加えることでOKとなった。
安易に変数を共通化した、とまでいうことはできないが、ステータス定義が甘かったんではないかと思われる。

こういう他人の粗探しというか、問題点の抽出作業というのは案外楽しいものだ(^^;
これが自分が担当しているシステムの話だと楽しいとか楽しくないという以前に気が気ではなくなるのだが……

|

« 衝撃! informixでも件数制限出来た | トップページ | うるさいダイアログ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/7792731

この記事へのトラックバック一覧です: 変数設計の難しさ:

« 衝撃! informixでも件数制限出来た | トップページ | うるさいダイアログ »