ふんづまってたことがようやくスッキリ
自分が作ったアプリケーションでは３つの環境で再現出来る事象が、
なんか他の人が作ったアプリケーションでは再現出来ない状態で、
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を持っていたということか。
なんかまだ気持ち悪いな。まあいいや、一旦忘れよう。
さて、全然違う件。
WebSphereのjythonについての話で、sqljのカスタマイズ・バインドをwsadminを使いつつやるというので、しっかりInformation Center通りにやろうとして失敗したことがある。
"-dburl"と思いきや実際は"-url"というオプションじゃないといけない。
AdminTaskのprocessSqljProfilesのとこだと再確認。
パラメータ説明のところは-dburlで載せてる。
jaclでは-urlで例を載せてて、jythonでは-dburlで載せてる。
こういう細かいのはどうしようかと思ってたら、
今まで気にしたこと無かったがページ下部にフィードバック用のメアドが載ってるようだ。
ふーん、気が向いたら書いてあげるよ。
