Spring FrameWork 3.X 問題点とかメモとか
■scoped-proxyの問題点
バグかどうか判らないが、SpringのSessionスコープオブジェクトには問題がある。
下図のような構造でセッションが終了すると、依存関係があるにも関わらず、Bean_Aが破棄される前にBean_Bが破棄されてしまう。
Bean_A -(依存)-> proxyObject -(依存)-> Bean_B
何が困るかというと、これではBean_Aのdestroyメソッド以下でBean_Bを使用できない、という事になる。セッション終了時にログアウトやら掃除やらをしようと思っても、NullPointerExceptionが発生してしまう。proxyObjectはキチンと残るんだが。。
単純なセッションスコープ同士の依存関係であればそもそもproxyは必要ないのでこの問題は発生しないが、例えばBean_Bが、SingletonであるBean_Cからも依存されている場合にはどうしてもproxyが必要になってしまうので、これは大変困る。
ということで私の知っている回避策は、
「Bean_Bに対してラッパークラスと実装クラスの2種類を用意する」こと。
ラッパークラスはSingletonのBeanから参照する時に用い、proxyを使用する。
実装クラスはBean_Aに相当するBeanから参照する時に用い、proxyを用いず純粋なSessionオブジェクトとする。美しくはないが、これでキチンと動作する。
■singletonオブジェクトのdestoryメソッド
singletonオブジェクトはSpringコンテキストが破棄される際に一緒に破棄されるので、やはりdestroyメソッドを使って掃除作業をしたくなることもあると思う。
とても使いやすいのだけれども、TransactionManagerが先に破棄されてしまう事がある(確実に発生するかは不明)。そうなるとTransactionを使用した処理が不可能になってしまうので、その場合はdepends-onにTransactionManagerのBean名を記載する。
■applicationContext.xml の書き方
・ロードタイムウィービング
<context:load-time-weaver/>
・@Configurableを使用する場合
<context:spring-configured/>
・コンポーネントスキャン
<context:component-scan base-package="jp.hoge"/>
・宣言的トランザクション(AspectJモード)
<tx:annotation-driven mode="aspectj"/>
・@PersistenceContextを使用してインジェクションするBean PostProcessor (jpa)
<bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />
AIX監視・測定あれこれメモ
■メモリサイズ確認
$ lsattr -El mem0
ent_mem_cap I/O メモリー・エンタイトルメント (KB) 偽
goodsize 15552 使用可能な物理メモリーの合計 (MB) 偽
mem_exp_factor メモリー拡張係数 偽
size 15552 物理メモリーの合計 (MB) 偽
var_mem_weight 可変メモリー容量の重み 偽
$ prtconf -m
メモリー・サイズ: 15552 MB
※AIXは空きメモリをファイルキャッシュで有効活用する為、メモリ使用率を単純に計測することにあまり意味はない
■あるポートを使用しているプロセスを特定する
$ netstat -Aan |grep 14248
f10007000864ebb0 tcp 0 0 *.14248 *.* LISTEN
$ rmsock f10007000864ebb0 tcpcb
The socket 0x864e808 is being held by proccess 143640 (java).
$ ps -ef |grep 143640
root 143640 127270 0 May 15 - 3:06 /var/opt/tivoli/ep/_jvm/jre/bin/java
■ポートの状態を確認する
# netstat -f inet -a -n
■プロセス単位のメモリ使用量計測
svmon -P [プロセスID] -i [インターバル] | grep [コマンド種別]
例)
svmon -P 11468916 -i 3 | grep java
DB2 9.7 INSERT\UPDATEトリガー
サンプル
======
CREATE OR REPLACE TRIGGER TRG_HOGE
NO CASCADE BEFORE UPDATE OR INSERT
ON HOGE_TABLE REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
BEGIN
IF INSERTING THEN
SET NEW.CREATE_DATE = CURRENT TIMESTAMP ;
SET NEW.UPDATE_DATE = CURRENT TIMESTAMP ;
ELSEIF UPDATING THEN
SET NEW.UPDATE_DATE = CURRENT TIMESTAMP ;
END IF;
END
@
======
このDDLを実行するときは
db2 -td@ -vf hoge.ddl
等とすること。そうしないと[;]でDDLが終わると認識されてしまう。
HibernateToolsをカスタムする
DBからEntityを自動生成する為にHibernateToolsを色々カスタムした記録
1.ReverseEngineeringStrategy
DelegatingReverseEngineeringStrategyを継承したStrategyを作成し、
Hibernateコード生成の構成から自作Strategyを指定。
EntityのスーパークラスやVersionカラムの指定などはこれが一番簡単。
2. CustomTemplate
HibernateToolsはPOJOやXMLの生成にfreemakerを使用している。
hibernate-tools.jarを展開すると*.ftlファイルがゴソっと入っているので、
これを編集→Hibernateコード生成の構成からカスタムテンプレートを指定する。
生成コードにべた書きされているような部分を書き換えるには、ここをカスタマイズする。(コメントとかね)
3.HibernateToolsのソースコードを取得して拡張
上記二つで対応できない場合の、最後の手段。
自分のパターンは「@EmbeddedIdではなく@IdClassを使った形式のEntityを生成したい」為に使用。
GitHubにてソースコードが公開されているので、これを改修→ビルドして使用、したいんだけど何故かコンパイルが通らない…原因調査中。。
まだ改修も何もしてないコードなんだけどなぁ…
原因判明。
どうやらJBoss Parent POMも必要らしい。
加えて、Hibernate-toolsのPOMに記述されているjboss-parentのバージョンが6のままだとコンパイルが失敗する。最新といわれる9に修正したら問題なくビルドされた。
但しNetBeans上だと読込み不可能扱い…ビルドは出来るんだけど。
あと、これまた原因不明だが単にビルドするとテストが走ってコケるので、
skipTest=trueをオプションとして加えた。
長かった・・・
ちなみに改修ソースは各種ftlファイルとBasicPOJOClass.java,EntityPOJOClass.java。