カテゴリ: JavaEE

6章。この本全部で33章あるんだが…1日1章として1ヶ月か。
・悲観的ロックと楽観的ロック。
 違いは後者は更新対象のローが他のトランザクションによって書き換わったか否かをロジックで判断する(排他ロックはしない)。後者の方が高速だけど判断が入るのでエラーの可能性がある。
・読み取り一貫性。いや、シリアライザブル以外はありえないだろ…。
 不正読み込み(ダーティリード、ノンリピータブルリード、ファントムリード)の図があって判り易い。
JTAトランザクション
 私、昔から接続プールとデータソースをそれぞれ別途定義する(普通1:1)のは何故かいな、冗長だなと思っていたが、JTAトランザクションの際にTXマネージャが同じ接続プールを渡す為だったのね。一つ利口になった。
・分散トランザクション
 JTAの理解が↑な有様にも関わらず、私は分散トランザクションと2フェーズコミットにはちと煩い男。というのも大昔、分散トランザクションモニタの汎用機からUnix系への移植の仕事をしてたのさ。Cで。でも下っ端だったんであんまり判らず。
EJBトランザクション
 まぁBMTは有りえないんでCMTだよな。Requied,RequiedNew,Supports,NotSupported,Mandatory,Neverの判り易い説明が。
・例外とトランザクション
 基本:非チェック例外(=ランタイムエラー系)は必ずロールバックされる。チェック例外(=論理エラー)はAPにExceptionを返しAPに判断させる。
 ただし、
  非チェック例外でもロールバックせずにAPに判断を任せる技(@ApplicationException(rollback=false)を明示)がある。
  チェック例外でも呼び出されたEJBでsetRollBackOnly()を読んでおくと必ずRollBackする。
・ステートフルセッションBean
 DBと違って、Bean自体のインスタンス変数の面倒はEJBコンテナではみてくれないので、javax.ejb.SessionSynchronizationのコールバックを実装しておくと、TX開始直前、コミット直前、終了直後、に呼ばれるのでそこで何とかする。

このエントリーをはてなブックマークに追加 mixiチェック

5章。DIの概要と、JavaEEでのDI。
DIって昔

JUnitイン・アクション

JUnitイン・アクション

を読んでやっとその意義が判ったクチ*1。それ以前は「コンテナ(=APサーバ)を変えても柔軟に対応できます」みたいな説明が多くて「途中でAPサーバを変える?SunかBEAかIBMが突如倒産しない限りやらないだろ…」とか思ってた。
JavaEE 5のDIでは、注入できるオブジェクトはEJBとかデータソース等、あらかじめ決まっている。Springのごとく何でもOKではない。
ちなみにこの注入というのは、変数宣言の前にアノテーションを書いておくと、実行時にコンテナがデプロイメントディスクリプタファイル読んでその変数に値を入れてくれること。デフォルトコンストラクタ中で注入は行なわれる。
注入先のオブジェクト、注入対象のオブジェクトがスレッドセーフか否かは一部実装依存なので超注意。95ページに注入先のオブジェクトが複数スレッドからの同時アクセスがあるか否かの表があるんで便利。
DI利用でのEJBテスト方法:EJB3.0用のソースはEJBコンテナ以からはアノテーションが無視される(=POJOに見える)事を利用する。
デフォルトコンストラクタはEJBコンテナが利用、引数付きコンストラクタを作って、これをテスト用に利用する(EJBコンテナが注入するメンバーをコンストラクタへの引数で初期化する)

*1:この本は判り易いけど、単体テストを自動化するために元のテスト対象クラスの設計をどんどん変えちゃう というのはちょっとやりすぎな感じが漂う。幾らリファクタリング流行だってなぁ…「メンバ関数の戻り値が修正前と同じだから大丈夫」は能天気過ぎだ。共有資源の排他とかOS固有の振る舞いの差とかUTで検出出来ない問題は多い。

このエントリーをはてなブックマークに追加 mixiチェック

3章と4章
3章はEJBの概要のほかは
・エンティティBeanの後継としてJPA規格がある。
・ローカル呼び出しとリモート呼び出しのスレッドに関する記述もある。

ローカル呼び出し
 ローカル呼び出しは(略)コンテナが割り当てる実行スレッドは、WebコンポーネントEJBコンポーネントで同一になります。(略)
リモート呼び出し
 リモート呼び出しの場合、コンテナが割り当てる実行スレッドは、WebコンポーネントEJBコンポーネントで別々になります。(略)

こないだ試したら同一EAR内からリモートインターフェース経由で呼んでも同一スレッドが処理してた件だけど何とこの本に

一部のJavaEEサーバ製品では、リモート用のビジネスインターフェースを利用していても(中略)同一のEARにパッケージングされている場合に限り(中略)ローカル呼び出し(参照渡し)に変更することができます。

と書いてあった。これかー→weblogic-ejb-jar.xmlのenable-call-by-reference。スピードアップの為だな。
4章 EJB2.1と3.0とのコードの記述量の差と後はセッションBeanのライフサイクルの話。
コードの記述量はまぁこうして全部見せられると確かに激減してるんだけど、実の所はIDE使うと現状の2.0でも3.0とあんまり変わらなかったり。ejb-jarやHomeインターフェースを手書きはしないだろみたいな。アノテーションもBEAの拡張まんまだし。つかBEAが先に実装してたのを規格にしたみたいな所も。
ライフサイクルはEJB3.0でも2.0と変わらない模様。
昔、よく知らない頃にステートフルSessoinBeanのメンバーにソケット持っててこれが不定期に謎の切断が起きた事があって原因はPassivateの時にシリアライズ失敗(ソケットは無理)してたというのがあった。
EJB3.0は2.1と違って、ソースコード上はEJBのインターフェースを継承してないのがポイントで、このお陰でPOJOに見えるからテストが楽と。

このエントリーをはてなブックマークに追加 mixiチェック

1章はEJB2.0の問題点→EJB3.0の利点
・デプロイメントディスクリプタ書くのが超面倒→ソース中のアノテーション
EJBコンテナへの依存→DIでPOJOっぽく
2章はEARの構造
・EAR,EJB-JAR,WARのディレクトリ構造とデプロイメントディスクリプタが纏まってる。
 JavaEE 5からはアノテーションのお陰で記述量が減ったり省略可だったりするそうな。
・クラスローディング
・JNDI
 よく、JNDIにアクセスするのにjava:comp/env/hogehogeといきなりhogehogeと両方有って謎だったんだがjava:comp/envは「JNDI ENC」っていうコンテナ固有のネーミングサービスとは別体系の模様。

このエントリーをはてなブックマークに追加 mixiチェック

→といいつついきなり18&19章 SOAP の所を読む。
Javaコード中のアノテーションWSDLとそのXMLスキーマの対応箇所が図示してあって判りやすい。名著決定。
ところで@SOAPBindingのパラメータスタイルはWRAPPEDがデフォルトだそうな。へー。UNWRAPPED(つかBARE)がデフォかと思ってた。
JAX-WSJAX-RPCの後継だけど非互換(ひでー)
JAX-WSJavaXMLの変換にJAXBを使ってる
・呼び出し形式は、同期・要求/応答型(HTTP)、一方向型(HTTP)、非同期(JMSとか)がある。一方向型と非同期の違い、一方向型はサービスメソッドが戻るまで待つ。
SOAPエンコードは既に死んでいる。
・結局、ドキュメント/リテラル ラップド が今後のデフォルト(ということにしたいらしい)。
WebサービスクラスはWAR、EJB-JARの二種類のデプロイ形式がある。セッションBeanにするときは後者。
SOAPハンドラ というものがある。サービス実装クラスの前にSOAPメッセージをインターセプトするクラス。ヘッダ情報をロギングするとかに使うらしい。

このエントリーをはてなブックマークに追加 mixiチェック

マスタリングJavaEE5 (CD-ROM付) (Programmer’s SELECTION)

マスタリングJavaEE5 (CD-ROM付) (Programmer’s SELECTION)

古本屋のネット通販で買ったら送料含めても新品より1000円安かった。それでも4000円超。だがしかし、この稼業は時に高い本も読まねばならぬのよ。8/27に出た本なのにもう古本屋に出るとは…。
Java EE5を全部バリバリ使うかというと多分使わないけど。つか(J2EEではなく)Java EEなんて使ってる人って居るのか?まーしかし全然知らないというのもいざという時にハマって徹夜とか残業とか大変な事になるので予防策といいましょうか何といいましょうか。どうでもいいがJ2EEの次なんだから素直にJ3EEにしろよ!と。
それはさておきやっぱ日本人の本は読みやすいな。外国翻訳モノはどうもイカン。章毎に寒い冗談めいた格言入れてたり。つか日本人の著書は適宜図を使うけど外人は長文でみっしりズラズラ書くっぽい。
とりあえずお家で毎日1章位ずつちょぼちょぼと通読しよう。

このエントリーをはてなブックマークに追加 mixiチェック

↑このページのトップヘ