JPAをプレーンJDBCdao実装と混合すると、どのような問題が発生する可能性がありますか？

debugcn 投稿 Dev

ギリ

異なるテクノロジーを使用して同じデータベースにアクセスしたい2つのチームがあります。1つはJPA（具体的にはHibernate）を使用します。もう1つはプレーンJDBCを使用します。

各チームが各テクノロジーのデフォルト構成や「ベストプラクティス」を使用していると仮定して、懸念事項のリストを作成するように依頼されました。

これは新しいデータベースであるため、スキーマがJPAチームのみ、またはJDBCチームのみによって設計されていると想像してください。その後、両方がデータベースにアクセスしようとします。

あなたの経験を共有していただけますか？

更新：私はここで意見を求めていません。JPAとJDBCのどちらが「優れている」かは関係ありません。2つのテクノロジーを組み合わせる際の相互運用性に関する懸念事項の客観的なリストを求めています。

これが私が探しているものの例です：

シナリオ：ユーザーが行を読み取り、メモリ内で変更して、データベースに保存し直します。

JPAversionが各テーブルに列を追加することにより、楽観的ロックを使用する場合。
トランザクションがコミットされると、JPAは、行が読み取られてから更新されるまでの間にバージョンが変更されたかどうかを確認します。バージョンが変更された場合、例外がスローされます。そうでない場合は、コミットを続行できます。
JDBC実装がテーブルロック（別名ペシミスティックロック）を使用する場合、それらはSELECT ... FOR UPDATE同時更新を防ぐために使用します。
JDBC実装がJPA規則を認識せずversion、コミット時に更新されない場合に何が起こるか想像してみてください。
1. JPAはを使用SELECTして行を読み取り、version1に等しいことを確認します。
2. JDBCは、を使用して行を読み取りますSELECT ... FOR UPDATE。
3. JDBCは、をインクリメントせずに行を更新します（トランザクションをコミットします）version。
4. JPAは行の更新を試みます。versionはまだ1に等しいため、コミットは実行されます。
5. JPA（ステップ4）は、JDBCの更新（ステップ3）を破壊しました。

教訓：JDBC実装は、version列を更新することを知っている必要があります。

ギリ

他の人が答えるのを待っている間に自分のリストを作成する：

JPAは、デフォルトでオプティミスティックロックを使用します。これには、バージョン列を追加し、行が更新されるたびにそれをインクリメントする必要があります。JDBCも同じことをする必要があります。
発散したDAOレイヤーは、発散したモデルになる可能性が高くなります。つまり、JPAマッピング構成が変更されるたびに、対応するJDBCコードがサイレントに中断する可能性があります。
JPAがカスケードルールを使用して更新または削除を伝播する場合。JDBCは同じことをする必要があります。
JPA@Id @GeneratedValue(strategy=GenerationType.SEQUENCE)を使用する場合は、シーケンステーブルを作成して使用します（例hibernate_sequence）。JDBCも同じことをする必要があります。
JDBCは、JPAクラス継承テーブルをサポートする必要があります。
JPAがスキーマの進化を推進する場合、JDBC実装はその規則/機能のサポートを追加する必要があります。一方、JDBCがスキーマの進化を促進する場合は、スキーマに影響を与えるJPA機能を無効にする必要があります。
データがJPAの外部で変更された場合、JPAの第2レベルのキャッシュを使用できません（crizzisの提供）