[JPA]永続性コンテキスト(4)-エンティティの変更

永続コンテキストの最後の残りの特徴変更検出(Dirty Checking)を理解し、永続コンテキストはこれで終了します.
まず、変更検出について理解し、次のコードを直接見てみましょう.
(メンバーテーブルにid(PK)が1、nameが「メンバー1」のデータが含まれていると仮定)
🎈 サンプルコード1

Member findMember1 = em.find(Member.class, 1L);
findMember1.setName("member2");
tx.commit();

🎉 ログ1

Hibernate: 
    select
        member0_.id as id1_0_0_,
        member0_.name as name2_0_0_ 
    from
        Member member0_ 
    where
        member0_.id=?
Hibernate: 
    /* update
        hellojpa.Member */ update
            Member 
        set
            name=? 
        where
            id=?

まず、idが1のメンバーデータをem.find()でクエリするので、selectクエリの出現は難しくありません.もちろん、このプロセスでは、データは永続的なコンテキストにキャッシュされ、より正確には、データはプライマリキャッシュにキャッシュされ、オブジェクトの参照値はfindMember変数に含まれます.次にsetterメソッドでmemberオブジェクトのname値を変更し、トランザクションをコミットします.
「えっ?どうして更新ドアが実行されたの?」という考えがありました.私はfindMemberオブジェクトのフィールド値を変更しただけで、DBやJPAに関するコードは作成されていません.値を変更するとupdate()のようなコードが必要になります(存在するかどうかはわかりませんが).
このような魔法のようなことが起こり得るのは、永久的なコンテキストの「検出変更」特性のおかげだ.下図を見る

上の図に示すように、メンバーオブジェクトがプライマリキャッシュに格納されたときに一緒に保存されるスナップショットと呼ばれるプライマリキャッシュが存在します.以降のトランザクションがコミットまたはリフレッシュ時に現在のエンティティ・オブジェクトとスナップショットを変更した場合、対応するUPDATE文が作成され、DBに送信されます.JPAはこの機能を「変更の検出」(Dirty Checking)と呼ぶ.
最後に、永続コンテキストの遅延ロード(Lazy Loading)には重要な特性があり、この部分は1つのmemberテーブルで説明するだけでは少し不足しているため、今回の永続コンテキストシリーズでは説明せずに、しばらく延期します.
これにより、永続性コンテキストの説明が終了します.書いても大したことはありませんが、言いすぎたようで、会社の言い訳をして、ブログを書く時間が長いです.今は会社を辞めても言い訳はありません.頑張って使います.😬