17

ドキュメントから

1000 000 行/オブジェクトを挿入する必要がある場合:

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();

なぜそのアプローチを使用する必要があるのでしょうか。StatelessSession 1 と比較して、どのような利点がありますか。

    StatelessSession session = sessionFactory.openStatelessSession();
    Transaction tx = session.beginTransaction();

    for ( int i=0; i<100000; i++ ) {
      Customer customer = new Customer(.....);
      session.insert(customer);
    }    

    tx.commit();
    session.close();

つまり、この（「代替」）最後の例はメモリを使用せず、同期する必要がなく、キャッシュを消去します。これは、このような場合のベストプラクティスであると思われますか? なぜ前のものを使用するのですか？

4

3 に答える 3

10

リンク先のドキュメントから：

特に、ステートレス セッションは、第 1 レベルのキャッシュを実装せず、第 2 レベルまたはクエリ キャッシュとも対話しません。トランザクションのライトビハインドまたは自動ダーティ チェックは実装されていません。ステートレス セッションを使用して実行される操作は、関連付けられたインスタンスにカスケードされることはありません。ステートレス セッションでは、コレクションは無視されます。ステートレス セッションを介して実行される操作は、Hibernate のイベント モデルとインターセプターをバイパスします。一次キャッシュがないため、ステートレス セッションはデータ エイリアシングの影響を受けやすくなります。

これらはいくつかの重大な制限です!

作成しているオブジェクトまたは行っている変更が、個々のオブジェクトのスカラー フィールドに対する単純な変更である場合、ステートレス セッションには、バッチ処理された通常のセッションと比較して不利な点はないと思います。ただし、もう少し複雑なことをしたい場合、つまりオブジェクトのコレクション値プロパティを操作したり、最初からカスケードされた別のオブジェクトを操作したりするとすぐに、ステートレス セッションは助けになるというよりも障害になります。

より一般的には、バッチ化された通常のセッションで十分なパフォーマンスが得られる場合、ステートレス セッションは単純に不要な複雑さになります。どことなく通常のセッションと似ていますが、APIやセマンティクスが異なり、バグを招きやすいものになっています。

確かに適切なツールである場合もありますが、これはルールではなく例外だと思います。

于 2013-01-05T17:28:03.830 に答える
-9

StatelessSession はバッチ処理をサポートしていません。
私が間違っていなければ、ドキュメントでこれを見まし
た StatelessSession によって提供されない機能と動作
• 第 1 レベルのキャッシュ
• 第 2 レベルまたはクエリ キャッシュとの相互作用
• トランザクションの後書きまたは自動ダーティ チェック
とバッチ処理はキャッシュを使用して行われます
許してください私が間違っている場合は私。

于 2013-01-19T15:01:30.280 に答える