読者です 読者をやめる 読者になる 読者になる

きどたかのブログ

いつか誰かがこのブログからトラブルを解決しますように。

ふんづまってたことがようやくスッキリ

自分が作ったアプリケーションでは3つの環境で再現出来る事象が、
なんか他の人が作ったアプリケーションでは再現出来ない状態で、
WebSphereの設定も含めて自分が思うように整えたうえでの事なので、
「環境に差によるものかもしれない」だとか、
「アプリの作り的にUOWManagerのローカルトラン配下では挙動が違うとか?」
などということを言っていたのだが、
今日やっているうちに明らかに間違えているコードが他の人が作った方にあることに気付いた。


MyConnectionContext con = new MyConnectionContext(con);
ExecutionContext econ = new ExecutionContext();
econ.setBatching(true);


あー、間違えとるやんけ。
ExecutionContextはConnectionContextから生成せなあかんやろ。
どうやってConnection渡しとんねん。


SQLJが生成するJavaのコードをしっかりと読み解いておけば、
こんな間違いを犯すことはないのだが、
みんながみんなそんな部分に興味を持たないのだろう。


この部分に気付くのに途方もなく時間をかけてしまった・・・。
もっと厳密にログを比較すべきだった。
明らかに例外が発生してる箇所が違ってた。
executeUpdate()で起こるか、executeBatch()で起こるかの違いなんだが、
その違いに気付くのがあまりにも遅すぎた。


もともとWSJdbcPreparedStatementが動いてることに非常に違和感を感じ続けていたのだが
これでようやく納得がいったのだ。
つまりはWSJccSQJConnectionから作ってないから、
本来使われるであろうWSJccPreparedStatementが動いてなかったのだ。
えっと、待て待て、そうするとExecutionContextは何かしらのConnectionを持っていたということか。
なんかまだ気持ち悪いな。まあいいや、一旦忘れよう。


さて、全然違う件。
WebSpherejythonについての話で、sqljのカスタマイズ・バインドをwsadminを使いつつやるというので、しっかりInformation Center通りにやろうとして失敗したことがある。
"-dburl"と思いきや実際は"-url"というオプションじゃないといけない。


http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rxml_atappmancommandsgroup.html


AdminTaskのprocessSqljProfilesのとこだと再確認。
パラメータ説明のところは-dburlで載せてる。
jaclでは-urlで例を載せてて、jythonでは-dburlで載せてる。
こういう細かいのはどうしようかと思ってたら、
今まで気にしたこと無かったがページ下部にフィードバック用のメアドが載ってるようだ。
ふーん、気が向いたら書いてあげるよ。