ハンズ・プロダクツ

お客さんのXPマシンがHDD障害により起動しなくなり、そのHDD換装でのOS再インストールのドタバタの覚書です。

まずは「効果絶大」を実証できたポイント。

何年か前に、このお客さんはＰＣを買い換えられて、アプリの操作サポートを行った際に、マイドキュメントをD:ドライブに変更しておきました。これは持論であるC:をヤラれて全滅しないように、データは極力D:へ・・・といった発想からです。モチロン素人さんにありがちなC:パンク寸前でD:はカラッポ・・・って状況も想定のウエで。

今回は、CDブートのlinuxで覗いても、HDD抜いて別マシンから覗いても、C：ドラは開けず、D:ドラが「ヒクヒク状態」で見えてる状態でした。モチロン、見えているうちにD:ドラのマイドキュメントやら、メンテナンスさせてもらっているアプリのバックアップディレクトリを退避させることで、D:ドラのデータはすべて戻すことが出来ました。（パチパチパチ）

やはり、別パーテーションのマイドキュメントは「アリなワザ」です。C:ドラが活きていれば、HDD換装なしにC:ドラのみのOS再インストールもアリですからね。

で、苦労した２つのポイント

まず、OS再インストールで、このマシンはレスキュー領域はなく、添付のDVDで再インストールのですが、その最中に「application error 19235」というエラーが出現。ちょいと調べれば、インストールを行うGhostのイメージファイルが壊れている・・・と。で、結局何が悪かったかとイウと、封も開けられていない新品のリカバリーディスクの汚れで、読めない・・・。なので、あらゆるクリーナーを使ってディスクを磨き上げ、別のちゃんとしたマシンでメディアのコピー作りにハゲみ、ダビ重なる読み取りエラーにもメゲズに、「拭いては→読み込み」を繰り返し、ラッキーにも読み取りに成功！。で、このコピー版で再インストールを実現したのであります。ネット調査の際に、「教えてhogehoge」的なサイトには、このメーカー(?)のこのあたりの機種(?)に質問が集中しているので、どうも媒体の品質の問題のようですね。そういえば袋から出すときに粘ってナカナカ出てきませんでした。

次に、OS(XP）がらみのアップデート作業です。これまた「XP アップデートできない」・・・といったトピックスが目白押しでした。で、この水飴のプールで泳ぐような・・・苦しみから抜けられた経験則は・・・In my case ですケド。まず、あの忌々しい「インターネットエクスプローラー」を単独で７から８に上げて、そして[windows update]ではなく[microsoft update](サイトの上の方にリンクあります)を使う・・・って、コレでなんとか苦しみから抜け出せました。

何事も、スムーズに行くとは限りません。心得ておるツモリです。しかし、HDD換装ゴトキで、こんなにハマルとは・・・。ああ、恐ろしやwindows。

これは、トホホなことです。

っま、いつものようにwebアプリの開発環境は、tomcat/spring/hibernate的なモノを使っておりまして、 CRUDに関しては特に、

• hibernateTemplate.save(hoge);
• hibernateTemplate.get(hoge);
• hibernateTemplate.update(hoge);
• hibernateTemplate.delete(hoge);

を、ゴシゴシと書くわけですね。

で、マスタ系のデータ（CSVファイル）をアップロードして、テーブルに更新するのに、最初のハナシの仕様では「総取り替え」だったので、さらに・・・

• hibernateTemplate.deleteAll(hoge);

で、コト足りたのです。ザッと単純なフローは、

1. テーブルのデータ全削除
2. CSVデータをテーブルにinsert

ははは・・・とても簡単！パイロット版を作って「よっしゃ！」っと、順調でした。

しかし、実際に現場でのヒアリングから、この仕様ではイカンことが判明し、行データ（件数）はCSVを使い、サーバーのテーブルに別途独自に保持された項目はイジラナイ・・・との仕様に変更になりました。

っま、思いついたフローの変更は・・・テーブルに変更Flgを追加しておいて、

1. テーブルの全データの変更Flgをfalseに（念のため） ●
2. CSVデータを順に読み込んで、
3. 一致データがあれば、必要項目と変更Flgをtrueに更新
4. 一致データがなければ、必要項目と変更Flgをtrueにしたレコードを追加
5. テーブルの更新Flgがfalseのものを削除 ●
6. テーブルの全データの変更Flgをfalseに ●

っま、こんなもんでしょ。っで、赤丸君 ● の、1,5,6 の箇所で、使ったのが、

• this.getSession().createQuery(deleteやらupdateのSQL文).executeUpdate();

みたいなネ。ちょちょいと動作確認できましたよ。おお、順調・ジュンチョウ・・・・。そして、念のため、連続的にアップロード処理を続けてみると、３回目（特定な処理タイミング）で、処理が帰ってこない・・・ガーン！

ログを見ると、ConnectionManagerがJDBCコネクションを開いたところで止まっている。この先はモチロンテーブルに更新が入るハズなのに・・・。

色々調べたら、Hibernateのキャッシュの問題・同一トランザクション内の実更新の順序の問題、っぽいのが気になったので、

• session.flush();
• session.clear();

やらを、色々入れて見るもダメ。泣きながら

• this.getSession().connection().createStatement().executeUpdate(deleteやらupdateのSQL文);

とかに「どーかヒトツ」っと、変更してみても・・・やはりダメ。

ああ、こりゃエライ壁にブチ当たってしまった！！！！！

でも、私は「カシコイ卑怯者」なので、以下で誤魔化すコトにした。例えば全フラグをfalseは・・・

List<Hoge> hoges  = hibernateTemplate.find(ぜんぶ);
for (int i=0; i<hoges.size(); i++) {
     hoges.get(i).setFlg(false);
     hibernateTemplate.update(hoges..get(i));
}

ざまあ見やがれ、１００回アップロードしても止まらないぜぃ！！！！！

・・・・何十行の処理だからスムけど、これじゃ根本的に解決していない。

ああああ、カユイ。・・・いつかお前を「ヤッツけてやる」。

【だったらイイな】

本番環境で、サーバーやらフレームワークをセットアップしたら、問題なく動作するとか・・・ね。

【ひょっとして】

昨年の春に、解析の相談を受けた某システムが、同じような現象だったなぁ。これだったのカモですね。

【追記】

翌日にフッと気づきました。

• hibernateTemplate.find(flgがfalseを取り出すSQL);

• hibernateTemplate.deleteAll(上で取り出したList);

これでも実装できるじゃん。

あと、気になるのは

• hibernateTemplate.doExecute(hoge);

これをもうチョイ調べれば「解決」があるカモ！

またこんな楽しい１日を過ごせたので、もう同じ１日を過ごさないようにメモ。

{CATALINA_HOME}\lib\(tomcat全体)と{CATALINA_HOME}\webApps\hogehoge\WEB-INF\lib\(各動作アプリ)のどちらに入れとくのか？っま、とりあえず共通であるtomcat全体に入れて、正常に動作していたのです。（いいね）

で、別のWebアプリを同じtomcat上で平行して動作させようと・・・。これは以前のtomcatと違って、webApps配下にポコンとディレクトリ作れば・・・html文章が見えた・・・ほら出来上がり。

じゃ、springの記述をして・・・あれ？エラーが出ちゃって見えなくなった。

で、ネットで色々探していたら、log4jは各動作アプリのlibに入れとかないと、設定は後出しの方が優先する・・・との記述がありました。

で、やってみると居るはずのクラスが見つからない・・・とのエラー。調べると依存している親元と子供との見え方に可逆性があるラシイ。

そこで、各アプリ毎にローカルで使われたがっていそうな連中を、入れ替えては様子を見たところ、今回のケースで、各アプリのlibに移動させたのは以下の通り。

• log4j.jar
• slf4j-api.jar
• slf4j-log4j.jar
• spring.jar
• spring-webmvc.jar
• hibernate3.jar
• dwr.jar

半日かかってやっと環境が準備できた。っま、こんなもんだ最初は！