Hibernate.orgCommunity Documentation

第15章 バッチ処理

15.1. バッチ挿入
15.2. バッチ更新
15.3. StatelessSession インターフェース
15.4. DML スタイルの操作

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 インスタンスをキャッシュするからです。

この章では、この問題を回避する方法を紹介します。しかしバッチ処理をするなら、 JDBC バッチが使用可能であることが非常に重要です。そうでなければ手頃なパフォーマンスが得られません。 JDBC バッチサイズを手頃な数値(例えば、10から50)に設定してください:

hibernate.jdbc.batch_size 20

identiy 識別子生成を使う場合は、Hibernate は JDBC レベルでインサートバッチングを無効にすることに注意してください。

また二次キャッシュが全く効かないプロセスで、このような作業をしたいと思うかもしれません:

hibernate.cache.use_second_level_cache false

しかし、これは絶対に必要というわけではありません。なぜなら明示的に CacheMode を設定して、二次キャッシュとの相互作用を無効にすることができるからです。

新しいオブジェクトを永続化するとき、一次キャッシュのサイズを制限するため、セッションを flush() して clear() しなければなりません。

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
   
for ( int i=0; i<100000; i++ ) {
    Customer customer = new Customer(.....);
    session.save(customer);
    if ( i % 20 == 0 ) { //20, same as the JDBC batch size
        //flush a batch of inserts and release memory:
        session.flush();
        session.clear();
    }
}
   
tx.commit();
session.close();

データを復元したり更新したりするには同じアイディアを適用します。それに加えて、データの行を多く返すクエリに対して有効なサーバーサイドのカーソルの利点を生かしたければ scroll() を使う必要があります。

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
   
ScrollableResults customers = session.getNamedQuery("GetCustomers")
    .setCacheMode(CacheMode.IGNORE)
    .scroll(ScrollMode.FORWARD_ONLY);
int count=0;
while ( customers.next() ) {
    Customer customer = (Customer) customers.get(0);
    customer.updateStuff(...);
    if ( ++count % 20 == 0 ) {
        //flush a batch of updates and release memory:
        session.flush();
        session.clear();
    }
}
   
tx.commit();
session.close();

また別の方法として、 Hibernate はコマンド指向の API を用意しています。これは分離オブジェクトの形で、データベースとのデータストリームのやり取りに使うことができます。 StatelessSession は関連する永続コンテキストを持たず、高レベルのライフサイクルセマンティクスの多くを提供しません。特にステートレスセッションは、一次キャッシュを実装せず、またどのような二次キャッシュやクエリキャッシュとも相互作用しません。トランザクショナルな write-behind や自動ダーティチェックも実装しません。ステートレスセッションを使って行われる操作が、関連するインスタンスへカスケードされることは決してありません。コレクションは、ステートレスセッションからは無視されます。ステートレスセッションを通して行われる操作は、 Hibernate のイベントモデルやインターセプタの影響を受けません。一次キャッシュを持たないため、ステートレスセッションは別名を持つデータに上手く対処できません。ステートレスセッションは低レベルの抽象化であり、 JDBC に非常によく似ています。

StatelessSession session = sessionFactory.openStatelessSession();

Transaction tx = session.beginTransaction();
   
ScrollableResults customers = session.getNamedQuery("GetCustomers")
    .scroll(ScrollMode.FORWARD_ONLY);
while ( customers.next() ) {
    Customer customer = (Customer) customers.get(0);
    customer.updateStuff(...);
    session.update(customer);
}
   
tx.commit();
session.close();

このコード例では、クエリが返す Customer インスタンスは即座に (セッションから) 分離されることに注意してください。これは、どのような永続コンテキストとも決して関連しません。

StatelessSession インターフェースで定義されている insert(), update()delete() の操作は、低レベルの直接的なデータベース操作と考えられます。結果として、 SQL の INSERT, UPDATE または DELETE がそれぞれ即座に実行されます。このように、これらは Session インターフェースで定義されている save(), saveOrUpdate()delete() とは非常に異なる意味を持ちます。

As already discussed, automatic and transparent object/relational mapping is concerned with the management of the object state. The object state is available in memory. This means that manipulating data directly in the database (using the SQL Data Manipulation Language (DML) the statements: INSERT, UPDATE, DELETE) will not affect in-memory state. However, Hibernate provides methods for bulk SQL-style DML statement execution that is performed through the Hibernate Query Language (HQL).

UPDATEDELETE 文の疑似構文は: ( UPDATE | DELETE ) FROM? エンティティ名 (WHERE 条件節)? です。注意すべき点がいくつかあります:

Some points to note:

  • from 節において、 FROM キーワードはオプションです。

  • from 節では単一のエンティティ名だけが可能で、任意で別名を付けることができます。エンティティ名に別名が与えられると、どのようなプロパティ参照も、その別名を使って修飾しなければなりません。もしエンティティ名に別名が与えられなければ、どのようなプロパティ参照も修飾してはなりません。

  • No joins, either implicit or explicit, can be specified in a bulk HQL query. Sub-queries can be used in the where-clause, where the subqueries themselves may contain joins.

  • where 節はオプションです。

例として、 HQL の UPDATE を実行するには、 Query.executeUpdate() メソッドを使ってください。(このメソッドはおなじみの JDBC PreparedStatement.executeUpdate() から名付けられました):

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
String hqlUpdate = "update Customer c set c.name = :newName where c.name = :oldName";
// or String hqlUpdate = "update Customer set name = :newName where name = :oldName";
int updatedEntities = s.createQuery( hqlUpdate )
        .setString( "newName", newName )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

In keeping with the EJB3 specification, HQL UPDATE statements, by default, do not effect the version or the timestamp property values for the affected entities. However, you can force Hibernate to reset the version or timestamp property values through the use of a versioned update. This is achieved by adding the VERSIONED keyword after the UPDATE keyword.

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
String hqlVersionedUpdate = "update versioned Customer set name = :newName where name = :oldName";
int updatedEntities = s.createQuery( hqlUpdate )
        .setString( "newName", newName )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

カスタムバージョン型(org.hibernate.usertype.UserVersionType)は update versioned 文と一緒に使えないことに注意してください。

HQL の DELETE を実行するには、同じ Query.executeUpdate() メソッドを使ってください:

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
String hqlDelete = "delete Customer c where c.name = :oldName";
// or String hqlDelete = "delete Customer where name = :oldName";
int deletedEntities = s.createQuery( hqlDelete )
        .setString( "oldName", oldName )
        .executeUpdate();
tx.commit();
session.close();

Query.executeUpdate() メソッドが返す int の値は、この操作が影響を及ぼしたエンティティの数です。これが影響するデータベース内の行数と、相互に関係するかどうかを考えてみてください。 HQL バルク操作は、結果として、実際の SQL 文が複数実行されることになります。例えば joined-subclass です。返される数は、その文によって影響された実際のエンティティの数を示します。 joined-subclass の例に戻ると、サブクラスの一つに対する削除は、そのサブクラスがマッピングされたテーブルだけではなく、「ルート」テーブルと継承階層をさらに下った joined-subclass のテーブルの削除になります。

INSERT 文の疑似構文は: INSERT INTO エンティティ名プロパティリスト select 文 です。注意すべき点がいくつかあります:

  • INSERT INTO ... SELECT ... の形式だけがサポートされています。 INSERT INTO ... VALUES ... の形式はサポートされていません。

    プロパティリストは、 SQL の INSERT 文における カラムの仕様 に類似しています。継承のマッピングに含まれるエンティティに対して、クラスレベルで直接定義されたプロパティだけが、プロパティリストに使えます。スーパークラスのプロパティは認められず、サブクラスのプロパティは効果がありません。言い換えると INSERT 文は、本質的にポリモーフィックではありません。

  • select 文の返り値の型が insert 文が期待する型とマッチしていれば、その select 文は妥当な HQL select クエリとなりえます。現在このチェックをデータベースへ任せるのではなく、クエリのコンパイル時にチェックします。このことは、 equal とは違い、 Hibernate の Type 間の equivalent に関する問題を引き起こすことに注意してください。これは org.hibernate.type.DateType として定義されたプロパティと、 org.hibernate.type.TimestampType として定義されたプロパティの間のミスマッチの問題を引き起こします。データベースがそれらを区別できなくても、変換することができても、この問題は発生します。

  • id プロパティに対して、 insert 文には二つの選択肢があります。プロパティリストで明示的に id プロパティを指定するか (この場合、対応する select 式から値が取られます)、プロパティリストからそれを除外するかのいずれかです (この場合、生成される値が使われます)。 後者の選択肢は、データベース内を操作する id ジェネレータを使うときのみ、利用可能です。この選択肢を採る場合、「インメモリ」型のジェネレータを使うと、構文解析時に例外が発生します。この議論では、インデータベース型ジェネレータは org.hibernate.id.SequenceGenerator (とそのサブクラス) と、 org.hibernate.id.PostInsertIdentifierGenerator の実装であると考えています。ここで最も注意すべき例外は、 org.hibernate.id.TableHiLoGenerator です。値を取得する選択可能な方法がないため、このジェネレータを使うことはできません。

  • versiontimestamp としてマッピングされるプロパティに対して、 insert 文には二つの選択肢があります。プロパティリストで明示的にプロパティを指定するか(この場合、対応する select 式から値が取られます)、プロパティリストから除外するか(この場合、 org.hibernate.type.VersionType で定義された シード値 が使われます)のいずれかです。

HQL の INSERT 文の実行例です:

Session session = sessionFactory.openSession();

Transaction tx = session.beginTransaction();
String hqlInsert = "insert into DelinquentAccount (id, name) select c.id, c.name from Customer c where ...";
int createdEntities = s.createQuery( hqlInsert )
        .executeUpdate();
tx.commit();
session.close();