« PHP の超便利オブジェクト指向,および PHP 所感 | トップページ | PostgreSQL トランザクションの隔離性 »

2010年1月17日 (日)

レガシーアプリケーション,だと...

O/R マッパーについて,改めて調べようと,"Hibernate in Action" (Bauer, 2005)1 を拾い読みしていて,行き当たった記述です.

Java アプリケーションが他のレガシーアプリケーションとデータベースのアクセスを共有するケースは多い.この場合,トランザクションスコープキャッシュを超えるどんな種類のキャッシュも利用すべきでない.なぜなら,キャッシュシステムにはレガシーアプリケーションがいつ共有されたデータを更新したかについて検知する方法がないからだ.

(Bauer, 2005, p.222)

ここでいう,「レガシーアプリケーション」とは, Hibernate を使用しない,あらゆるアプリケーションであり, Hibernate を利用できない,あらゆる開発言語のことですよね.

FORTRAN, COBOL はもちろん, C/C++ も含むと.さらに, Perl, Python, Ruby, PHP であるとか, Haskell, Eralng といった,開発言語も含まれているわけです.

Java と .NET に限定される,と言った方が早いですね.

NHibernate for .NET

この NHibernate とやらは, Java の Hibernate とキャッシュの同期をやるのですかね. .NET CLR 上で動作するとすると, Java VM とは別プロセスで動くはずで,そうすると,キャッシュの同期をやるには,プロセス間通信(クラスタリング)が必要になるはず.

2005 年に発行された本の内容ですので,今は違うのかもしれませんけど.でも,データベース側の変更を検知して,キャッシュのコントロールをしている,となると,それはそれで,アプリに無駄な複雑さを持ち込んでいる感じはあります.

キャッシュはデータベースへのアクセスを避けるために,次のような場合に試みられる.

● アプリケーションが識別子(主キー)によるルックアップを実行する.

● 永続化レイヤが関連を遅延して解決する.

クエリの結果をキャッシュすることも可能である.しかし,7章で論じるようにクエリ結果のキャッシュがパフォーマンスに与える影響はほとんどの場合わずかである.したがって,この機能の利用頻度は低いものである.

(Bauer, 2005, p.218)

O/R マッパーの発行する SQL のパフォーマンスが低いから,それを緩和するために,メモリへのキャッシュが必要,といっているようにしか読めませんね.

駄目な技術を何とか使えるように,あれこれと手立てを講じているように思えるのは気のせいか?

何か, RAID (Redundant Array of Inexpensive Disks) のパリティ方式,RAID2 -> RAID3 -> RAID4 -> RAID5 -> RAID6 を彷彿させますね.


1. Christian Bauer, Gavin King. "Hibernate in Action". Manning Publications, 2005. 倉橋 央, 勝嶌 和彦. "Hibernate イン アクション". ソフトバンク クリエイティブ, 2006.

|

« PHP の超便利オブジェクト指向,および PHP 所感 | トップページ | PostgreSQL トランザクションの隔離性 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/33014004

この記事へのトラックバック一覧です: レガシーアプリケーション,だと...:

« PHP の超便利オブジェクト指向,および PHP 所感 | トップページ | PostgreSQL トランザクションの隔離性 »