JPOUG Tech Talk Night #2 で話した内容に飲み会で質問された内容を加えています。
これはJava EE Advent Calendar 2013の21日目 昨日は[twitter:@Hachiro808]さんのThymeleafを業務で使いたいでした。 皆様はJPAのL2キャッシュというものをご存知でしょうか。 L2キャッシュとは エンティティをキャッシュし、複数のスレッド間でエンティティを使ってデータをやりとりする場合にいちいちデータベースにアクセスしなくて良くするためのキャッシュです。 普通にエンティティのキャッシュです。ちなみにL1キャッシュというのもありまして、そちらは同じスレッド内で同じエンティティを取得する場合に毎回DBにアクセスしに行かなくて良くするためのキャッシュです。 詳しくはOracleの人が書いた資料があったのでそちらを参照してください。 JPAのキャッシュを使ったアプリケーション高速化手法 超クセモノなL2キャッシュ とまあ、字面だけ見ると非常に
JPAだけで完結するのはさすがにムリがあったのでこういうタイトルにした。が、JPAプロバイダ固有のAPIのレベルではフェッチサイズを変更する効果を確認できた。 JDBCのsetFetchSize変更時の動きをstatspackで見てみる - kagamihogeの日記ではJDBCを直接使用していたが、このエントリではJPAプロバイダ(EclipseLink, Hibernate)固有のAPIを使用して100万行取得するコードの速度を、フェッチサイズ変更無しと100の時とでどのくらい速度差が生じるかを確認する。 環境 DB CentOS-6.4-x86_64 Oracle Database Express Edition 11g Release 2 Java Java SE Development Kit 7u45 Eclipse Kepler(4.3.1) SR1 IDE for Java
Hibernate を使ってデータベースに100,000行を挿入する愚直な方法は、このようなものです: Session session = sessionFactory.openSession(); Transaction tx = session.beginTransaction(); for ( int i=0; i<100000; i++ ) { Customer customer = new Customer(.....); session.save(customer); } tx.commit(); session.close();これは50,000番目の行のあたりで OutOfMemoryException で失敗するでしょう。 Hibernate がセッションレベルキャッシュで、新しく挿入されたすべての Customer インスタンスをキャッシュするからです。 この章では、こ
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
業務アプリケーションを作っていると、監査証跡ということで、作成者、作成日時、更新者、更新日時を保存するということがあると思います。Spring Dataのアノテーションを使うと、自動でセットしてくれるので、アプリケーションで決まりきったコードを書かなくて済むということみたいです。 Task.java(モデルクラス) package sample.model; import org.springframework.data.annotation.CreatedBy; import org.springframework.data.annotation.CreatedDate; import org.springframework.data.annotation.LastModifiedBy; import org.springframework.data.annotation.LastMod
@Entityアノテーションと@Idアノテーション @Tableアノテーション @GeneratedValueアノテーション @Columnアノテーション @Transientアノテーション @MappedSuperclassアノテーション 次回は @Entityアノテーションと@Idアノテーション まずは、これが無いと始りません。@Entityは該当のクラスがエンティティであることを指定し、@Idはプライマリキーとなるプロパティかフィールドを指定します。 @Entity public class Customer { @Id private Long id; private String firstname; private String lastname; // ・・ } @Idは以下の様に指定することもできます。というかこっちの方が一般的か? @Id public Long getI
このエントリでは、Grzegorz Gajosによる記事、How Hibernate Almost Ruined My Careerを紹介する。 (Grzegorzから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 想像してくれ。 君はJava開発者で、次のビッグプロジェクトを開始しようとしているところだ。 君は、そのプロジェクト全体に影響する根本的な決断をする必要がある。 君の柔軟なデータモデルをオブジェクト指向で抽象化するベストな方法を選択したい。生のSQLを扱いたくはないからね。 どんな種類のデータもサポートしたいし、理想では全種のデータベースをサポートしたい。 すぐに思いつくのは、単にHibernateを使うという解だ。そうだろ? Javaディベロッパの90%は君に同意するだ
関連エンティティのfetch方法を指定する設定値をデフォルト値から変更した方がよいケースの具体例について。
6.4.1. Overview¶ 排他制御とは、複数のトランザクションから同じデータに対して、同時に更新処理が行われる際に、データの整合性を保つために行う処理のことである。 複数のトランザクションから同じデータに対して、同時に更新処理が行われる可能性がある場合は、基本的に排他制御を行う必要がある。 ここで言うトランザクションとは、かならずしもデータベースとのトランザクションとは限らず、ロングトランザクションも含まれる。 Note ロングトランザクションとは データの取得とデータの更新を、別々のデータベーストランザクションとして行う際に発生するトランザクションのことである。 具体例としては、取得したデータを編集画面に表示し、画面で編集した値をデータベースに更新するようなアプリケーションで発生する。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く