JPA学習、#1
5054 ワード
次の内容は、金ヨンハンのJava ORM標準JPAプログラミングの内容に基づいてまとめられた文章だ.
現在のポイントでオブジェクトを永続的に保存する方法では、最も現実的な代替案はリレーショナル・データベースです.ただし、リレーショナル・データベースとオブジェクト向けの間には、パターンが一致しません.したがって、オブジェクトをオブジェクトとしてモデリングするほど、2つのモードの不一致を解決するのに時間とコードがかかります.したがって、最終アプリケーションはデータベースを中心としたSQLを中心とします.
大量の繰返しタスク(crudクエリーの作成と変更) は、実際に使用するオブジェクトを特定するためにSQLを表示する必要があるため、データ・アクセス・レイヤを完全に分離することは困難です. エンティティは信頼されていません(実際に実行されているSQLを表示するまでクエリーのオブジェクトを特定できません) 継承(オブジェクト)とスーパータイプサブタイプ関係(DB) 関連付け(参照(オブジェクト)と外部キー(DB) オブジェクトグラフィックナビゲーション(参照(オブジェクト)vs SQL時接続(DB) データ識別方法(同一性、同一性(対象)vsプライマリキー値(DB) これらの問題では,Java集合のようにオブジェクトをDBに保存できるかどうかが考えられるようになった.だから生まれたのはJPA
Java陣営のオブジェクト-リレーショナルマッピング(ORM)技術標準. の具体的な実装フレームワークには、HyperNate、EclipseLinkなどが含まれるが、最も多く使用されているのはHyperNateである. オブジェクトとテーブルをマッピングすることによって、モード不一致の問題を解決するフレームワーク. はSQLを自動的に生成し、パターンの不一致を解決するため、開発者はリレーショナル・データベースを使用してオブジェクトをガイドとしてアプリケーションを開発することができます. 生産性(冗長な重複CRUD SQLを自動的に生成) メンテナンス(SQLに依存せず、エンティティ変更時にメンテナンスが必要なコードを減らす) パターンの不一致(上記の不一致問題を解決することにより、オブジェクト向けにアプリケーションを開発する) パフォーマンス(プライマリキャッシュ、ライト遅延、インスタント/遅延ロードなど多様な最適化を含む) .データアクセス抽象化およびベンダー独立性(特定のデータベースに依存することなくデータベースとアプリケーションの間に抽象的なデータアクセス層を提供する) .規格(他の実施技術に簡単に変更可能)
エンティティの格納、変更、削除、問合せなど、エンティティに関連するトランザクションを処理します. エンティティを格納する仮想データベース、 エンティティファクトリによる作成(データベースごとに1つのファクトリで、アプリケーション全体で共有できるコストが高い) の同期性の問題のため、エンティティマネージャはスレッドごとに1つ割り当てます. データベースに接続する必要があるまで、データベース接続は取得されません. エンティティを永続的に格納する環境として、エンティティマネージャはエンティティを永続的コンテキストに保存して管理します. エンティティーマネージャを作成すると、エンティティーマネージャが作成され、エンティティーマネージャによってアクセスおよび管理されます. は、通常、1つのトラック測定単位に保持される. 複数のエンティティーマネージャは、同じ永続性コンテキストにアクセスできます. 非永久性(永久性試験とは無関係) 永続性(永続性コンテキストに格納、管理者によって管理されるエンティティ) .準零速(永続性試験に格納後分離) (永続コンテキストおよびデータベースからエンティティを削除)
次の利点があります.
プライマリキャッシュ メモリにはプライマリキャッシュが存在し、エンティティクエリー時にデータベースクエリーの前にキャッシュでクエリーします. 永続コンテキストは、消失と同時に消失し、実際にはパフォーマンスに大きなメリットはありません.
同一性 プライマリキャッシュに存在する特定のエンティティを繰り返し呼び出しても、同じインスタンスが返されます. アプリケーション・レベルで、トランザクション独立性レベルがREPEATABLE READであることを確認します.
書き込み遅延
エンティティの登録時 エンティティーマネージャによってエンティティーが永続化されると、エンティティーマネージャはエンティティーを分析してinsert queryを生成し、遅延書き込みのSQLリポジトリに格納します. 以降、トランザクションがコミットされた瞬間に、書き込み遅延SQLリポジトリで収集されたクエリがデータベース に送信される hibernate.jdbc.batch size設定により、スタックされたクエリーをバッチ・クエリーに一度に送信できます. ただし、エンティティのIDが@GeneratedValue(strateg=GenerationType.IDENTITY)に設定されている場合、batchinsertは機能せず、永続性とともにinsert queryをデータベースに送信します.詳細リンク
エンティティの変更 でポイントをリフレッシュし、エンティティのsnap shot(初期状態)を実際のエンティティと比較してupdatequeryを生成し、変更した部分を遅延書き込みのリポジトリに送信します.これはデータベースに再送信されます. このような変更検出機能をdirtyreadと呼ぶ. updatequeryは、変更を生成する部分だけでなく、すべてのフィールドをupdatequeryに含めます. の利点は、常に同じ変更クエリーを有し、事前に生成および再使用することができることである.データベースが同じクエリーを提供する場合、パケット化されたクエリー を再使用することができることである.欠点は、データ転送量が 増加することである. @org.hibernate.annotations.DynamicUpdateプレゼンテーションでは、UPDATE SQLを生成するポリシーを変更し、一部を変更するだけでupdate queryを作成できます. 一般的には、欄数が30個を超えると基本的な方法が遅くなる可能性がありますが、直接テストして更新するのが遅すぎる場合は、その時になってから修正することをお勧めします. 変更検出は、永続コンテキストによって管理する永続状態エンティティ にのみ適用される.
エンティティの削除 エンティティ削除は、削除クエリーを遅延書き込みリポジトリに登録し、flushを呼び出すとクエリーをデータベースに渡します.
ディレイロード では、最初からデータベースでクエリーするのではなく、実際に使用するときにデータベースから関連オブジェクトをクエリーできます.
永続コンテキストへの変更をデータベースに反映する の変更を検出して変更クエリーを作成する->書き込み遅延SQLストレージクエリー送信データベース FlushModeType.AUTO(デフォルト)、FloushModeType.COMMIT(コミット時のみリフレッシュ)には2つのモードがあります: flushを呼び出す3つの方法ダイレクトコール トランザクションのコミット時に が自動的に呼び出されます. JPQLクエリ実行前自動コール 持続コンテキストによって管理する持続状態エンティティは、持続コンテキストから 分離される.の永続性コンテキストが提供する機能 は使用できません.を準永久状態にする方法 分離(entitty)エンティティに関するすべての情報は、永続的コンテキストにおいて から消失する. clear()持続コンテキストを初期化し、含まれるすべてのエンティティを準持続状態にします. close()持続コンテキストを終了し、含まれるすべてのエンティティを準持続状態にします. プロパティ は、非永続性に近い永続性コンテキストで提供される機能を実行しません. はすでに漢英属状態にあるため、識別子が存在する. mergeは、save or update機能を実行するゼロまたは非ゼロのステータスエンティティをゼロに変更します.
JPAの背景
現在のポイントでオブジェクトを永続的に保存する方法では、最も現実的な代替案はリレーショナル・データベースです.ただし、リレーショナル・データベースとオブジェクト向けの間には、パターンが一致しません.したがって、オブジェクトをオブジェクトとしてモデリングするほど、2つのモードの不一致を解決するのに時間とコードがかかります.したがって、最終アプリケーションはデータベースを中心としたSQLを中心とします.
SQLを直接使用する場合の質問
具体的なパターンの不一致問題
JPA欄
ORMは
なぜJPAを使うのですか?
持続性管理
エンティティーマネージャ
持続性コンテキスト
エンティティのライフサイクル
entityManger.persist(객체)
entityManger.close() 영속성 컨텍스트 닫기
or
entityManger.clear() 영속성 컨텍스트를 초기화
or
entityManger.detach(객체) 영속성 컨텍스트에서 분리
削除entityManger.remove(객체)
永続線コンテキストが必要なのはなぜですか?
次の利点があります.
プライマリキャッシュ
同一性
書き込み遅延
エンティティの登録時
エンティティの変更
エンティティの削除
ディレイロード
flush
いつまでも続く
Reference
この問題について(JPA学習、#1), 我々は、より多くの情報をここで見つけました https://velog.io/@wnwl1216/JPA-스터디-1テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol